+1
Am 06.12.14 um 20:57 schrieb Andres Almiray:
I'd rather be pragmatic and use "annotations" right away.
This way we can get a feeling of the API. We can later rename it to
something that fits the behavior better based on experience.
My policy for making breaking changes (such as package names
+1
I also filed a JIRA ticket on another issue (that one's really a bug;-)
@Anatole
Are you or others able to add a few basic components like "API", "Core",
etc. in JIRA?
Thanks,
Werner
On Mon, Dec 8, 2014 at 12:20 PM, Anatole Tresch wrote:
> Summarizing I suggest we go on with 'annotation'
Summarizing I suggest we go on with 'annotation' as of now and focus on
other topics As said we can rethink this still later, if necessary. If not
I am fine with that ;) if somebody has troubles with that let me know.
i saw that CMS is now answring request on our project site, so we should
start a
Especially concrete tasks are better turned into a JIRA ticket.
That's where I made remarks about this issue and the owner of the ticket
addressed it, usually better to see, what was done and what wasn't;-)
On Mon, Dec 8, 2014 at 11:56 AM, Werner Keil wrote:
> I don't continue the discussion be
I don't continue the discussion because for now (similar to e.g. what
Andres suggested, the singular vs. plural is just marginal, more important
to have a descriptive name for now;-) Anatole fixed it, so I don't even
know who might have continued the discussion, but I don't see a reason.
At Device
@werner:
although i appreciate the commit (if you mean that), it sounded like you
continued with the discussion because you don't agree.
if we have an agreement, we are done. otherwise it needs to be resolved
(independent of a commit).
regards,
gerhard
2014-12-07 21:19 GMT+01:00 Werner Keil :
It seems, Anatole already addressed the issue;-)
Whether other forms of package-naming beyond that is desired, I guess we
should do a vote or draft options in the Wiki first?.
Regards,
Werner
On Sun, Dec 7, 2014 at 9:13 PM, Gerhard Petracek wrote:
> in many cases you can list x frameworks or s
in many cases you can list x frameworks or specs. which follow a specific
approach.
however, it sounds like we need a vote about using a meaningful (or no) vs.
a generic package-name.
regards,
gerhard
2014-12-07 16:04 GMT+01:00 Werner Keil :
> Pretty much every Java EE technology does and they
Pretty much every Java EE technology does and they'll get even more with EE
8;-)
Hence it makes sense for a project that also aims at EE aside from
standalone app configuration.
Werner
On Sat, Dec 6, 2014 at 10:21 PM, Romain Manni-Bucau
wrote:
> servlet uses annotation package not sure why. Fo
servlet uses annotation package not sure why. For me either it was a
miss or just a "put all in a new package" idea but it looks weird for
me as a user.
CDI uses javax.annotation cause CDI didnt have the choice
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress
Don't forget, CDI uses all these annotations from javax.annotation like
ManagedBean, etc.;-)
On Sat, Dec 6, 2014 at 9:36 PM, Werner Keil wrote:
> What does Servlet use?
> Aside from being called "javax.servlet" not "javax.servlets";-)
>
> "faces" is among the few Java standards where the packag
What does Servlet use?
Aside from being called "javax.servlet" not "javax.servlets";-)
"faces" is among the few Java standards where the package contains a
plural, but it's part of the standard name, so it makes sense.
Then again, the JSF package "javax.faces.component" could be called
"javax.fac
spring is far to be a modern framework regarding this aspect...CDI,
JAX-RS, BeanValidation, JTA, JPA etc...don't use it. Servlet uses it
but surely something missed in EG (at least @EE level).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github
Speaking of pseudo- or de-facto-standard (or the home of Groov/Grails;-)
Spring Framework also calls these packages always "annotation", see
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/package-summary.html#package.description
Werner
On Sat, Dec 6,
Hibernate seems to be among the few cases where such package is called
"annotations", but then it is not really consistent, given other packages
are called "exception" rather than "exceptions". So either multiple teams
worked on those or names were picked pretty randomly;-)
Werner
On Sat, Dec 6,
Why "annotations" not "annotation"?
Of course if we plan to change it, we might as well keep "annot" for now;-)
On Sat, Dec 6, 2014 at 8:57 PM, Andres Almiray wrote:
> I'd rather be pragmatic and use "annotations" right away.
> This way we can get a feeling of the API. We can later rename it to
I'd rather be pragmatic and use "annotations" right away.
This way we can get a feeling of the API. We can later rename it to
something that fits the behavior better based on experience.
My policy for making breaking changes (such as package names) is:
- break as much as you can during pre 1.0 in
I think we implicitely wait for some more proposals no?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-06 20:40 GMT+01:00 Werner Keil :
> OK, so it's still about calling one or several packages "binding" or
> what
OK, so it's still about calling one or several packages "binding" or
whatever and not use an "annot*" one at all?
There have been a couple of +1 for the longer version. It also depends on
what useful packages would be, maybe better to draft this in the Wiki than
an endless thread?;-)
On Sat, Dec
but google gives more inputs with binding than annotation; What I
meant is annotation is quite neutral today. Well I think my opinion
is clear now :)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-06 20:32 GMT+01:
Jackson DataBind also calls it "annotation"
http://fasterxml.github.io/jackson-databind/javadoc/2.2.0/com/fasterxml/jackson/databind/annotation/package-frame.html
Some other Jackson APIs even prefer the package name "annotate" over
"annotation" or "annotations";-)
Werner
On Sat, Dec 6, 2014 at 8
In most cases you'd enter "Tamaya JavaDoc" or something.
The new Lambda package used to be named "java.util.functions" in
pre-releases of Java 8 but was then renamed to the singular version
"java.util.function"
Anyway, unless we keep the cropped version after all something like a
survey could wo
"hibernate mapping" vs "hibernate annotation", seems the first one
wins. Same for "jackson binding" vs "jackson annotation". Then theonly
challenge is to have a good doc but I have no doubt we'll get there.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
What do I enter into the Google search field? Tamaya config annotations
So, having a annotations package is user and search engine friendly.
Oliver
Am 06.12.14 um 20:07 schrieb Romain Manni-Bucau:
s/majority of projects/majority of *old* projects/ which means it is
surely time to stop followin
+1
Am 04.12.14 um 14:56 schrieb Gerhard Petracek:
@andres:
i also saw it just as an example from romain.
the important part is to use useful package-names which are to the point
(whatever the point is).
regards,
gerhard
2014-12-04 14:51 GMT+01:00 Romain Manni-Bucau :
@Anders: i agree but i
If they are part of the Java EE Standard, then calling it "old" means you'd
rather abandon a standard and create your own pseudo-standard?;-)
You won't see somebody just throwing random annotations into a "new"
package "javax.enterprise.annotations" just because a few people might find
"annotation
s/majority of projects/majority of *old* projects/ which means it is
surely time to stop following blindly others ;)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-06 20:04 GMT+01:00 Werner Keil :
> The majority o
The majority of projects or standards (especially Java SE or EE) calls it
"annotation".
With very few exceptions, plural for package names is rare to non-existent.
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer |
.com/rmannibucau
> >>
> >>
> >> 2014-12-06 10:27 GMT+01:00 Anatole Tresch :
> >> > Reading again I would really encourage to write a short proposal ;) I
> >> think
> >> > we are not far away from each other...
> >> >
bucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-06 10:27 GMT+01:00 Anatole Tresch :
>> > Reading again I would really encourage to write a short proposal ;) I
>> think
>> > we are not far away from each other...
>> >
+01:00 Anatole Tresch :
> > Reading again I would really encourage to write a short proposal ;) I
> think
> > we are not far away from each other...
> > -- Forwarded message -----
> > From: Anatole Tresch
> > Date: Sa., 6. Dez. 2014 um 10:25
> > Subject:
27 GMT+01:00 Anatole Tresch :
> Reading again I would really encourage to write a short proposal ;) I think
> we are not far away from each other...
> -- Forwarded message -
> From: Anatole Tresch
> Date: Sa., 6. Dez. 2014 um 10:25
> Subject: Re: "annotati
Reading again I would really encourage to write a short proposal ;) I think
we are not far away from each other...
-- Forwarded message -
From: Anatole Tresch
Date: Sa., 6. Dez. 2014 um 10:25
Subject: Re: "annotation" instead of "annot"
To:
Sure? A @Config
Sure? A @Config qualifier cannot be isolated (without additional
qualifiers), so given 2 configurations all change events sre sent to each
observer.
Additionally using a qualifier adds a dependency to cdi for the Qualifier
meta annotation. Given that we are at square. 0 again: diy...
And last I thi
actually with CDI 1.0 we can already do advanced things using a Config
qualifier so we can send the event to listeners of 1 bean, 1 area, 1
property...
Only issue is: how do we do in standalone. I would design it the same
way but without the @Observes (= need configBus.register(myListener).
wdyt?
I know ;) Looking at the integration with CDI, where we do probably parts
of the injection ourself (especially to support CDI earlier to CDI 2.0), I
would propose @ConfigUpdate (working title) to be a config related feature.
We can additionally publish any *ConfigChange *events on the CDI bus/to
Sp
The point is the "bus" design is different "by framework". Standalone
-> DIY, CDI -> @Observes with an event you expect and config
management is delegated to another bean (in the idea), Spring ->
listener interface...
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wor
I would like to see a similar feature set in SE only as well as with
CDI/Spring. Also the listener/event functionality will probably not be 100%
similar as in CDI (I see use cases, where an instance is only informed on
config changes affecting the instance, but not the rest of the system). I
also s
Ok. Wonder if the listener annotation makes sense btw. We can use an
interface in standalone and I am sure we ll strongly type it to integrate
it with spring cdi etc.. giving the property change event and the config
object instance.
Wdyt?
Le 6 déc. 2014 02:13, "Anatole Tresch" a écrit :
> Hi all
Hi all
I would simply put all into a package called *mapping*, based on the
discussions we had this looks most feasible for me For met that looks good.
If we have more event related annotations, we might reconsider adding an
additional one.
WDYT?
Anatole
2014-12-05 19:44 GMT+01:00 Romain Manni
annotation or annotations? :p.
More seriously: what's the issue with "mapping" for @ConfiguredX,
@WithX - we'll surely need to rename it to something more intuitive -
and dynamic, event, listener for @ConfigChangeListener?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibu
+1 because it helps us to find what we need... IMHO
Am 05.12.14 15:38, schrieb Otávio Gonçalves de Santana:
full name is really better.
"org.apache.tamaya.annotation",
On Wed, Dec 3, 2014 at 11:51 AM, Werner Keil wrote:
Hi,
Looking not only at Java EE (http://docs.oracle.com/javaee/7/api/)
full name is really better.
"org.apache.tamaya.annotation",
On Wed, Dec 3, 2014 at 11:51 AM, Werner Keil 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 alread
Just look at Log4J it features pretty much the most common backings for
configuration sources there already;-)
On Thu, Dec 4, 2014 at 3:22 PM, Romain Manni-Bucau
wrote:
> the API will be light but the core should be as well otherwise it will
> be a blocker for adaption for much libraries
>
>
the API will be light but the core should be as well otherwise it will
be a blocker for adaption for much libraries
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-04 15:17 GMT+01:00 Werner Keil :
> For the API abs
For the API absolutely, and more importantly modular.
Look at Log4J a lot of it is done on an implementation level (hence it
could in theory implement additional projects like Tamaya if it becomes
suitable, maybe we should talk to the Log4J team over synergies;-)
On Thu, Dec 4, 2014 at 3:13 PM
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 :
> While I totally agree, annotations should be defined on an API level and be
> independent of implementatio
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.
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 fo
@andres:
i also saw it just as an example from romain.
the important part is to use useful package-names which are to the point
(whatever the point is).
regards,
gerhard
2014-12-04 14:51 GMT+01:00 Romain Manni-Bucau :
> @Anders: i agree but it doesn't mean we need to call packages
> "something
@Anders: i agree but it doesn't mean we need to call packages
"something". Mapping, binding etc seems more appropriate for half of
them and listener/event for the other part, wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannib
@romain: +1
(i was going to write something similar - let's use useful package-names)
regards,
gerhard
2014-12-04 14:45 GMT+01:00 Romain Manni-Bucau :
> tamaya config cdi -> cdi package?
> tamaya pojo binding -> binding package?
>
> annotation is way too generic to help anyone, it is like sear
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
requirement
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
@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? Ther
@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 :
> The
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
+1 for annotation. Feels like a standard and is usefull for
"autocompletion" programmers... ;-)
Am 03.12.14 14:51, schrieb Werner Keil:
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", e
@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
should belong (has
maximal cohesion or similar)...
-Original Message-
From: Werner Keil [mailto:werner.k...@gmail.com]
Sent: Mittwoch, 3. Dezember 2014 15:59
To: dev@tamaya.incubator.apache.org
Subject: Re: "annotation" instead of "annot"
Many Java standards do, but
Many Java standards do, but underlying CDI is an example where it was also
done differently.
Agorava another popular downstream user of CDI (and DeltaSpike to some
extent) has a dedicated "exceptions" package, but also does not handle
annotations separately.
Werner
On Wed, Dec 3, 2014 at 3:50 PM,
@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).
re
rt
> discussions on them ;)
>
> WDYT?
>
>
> -Original Message-
> From: Werner Keil [mailto:werner.k...@gmail.com]
> Sent: Mittwoch, 3. Dezember 2014 15:25
> To: dev@tamaya.incubator.apache.org
> Subject: Re: "annotation" instead of "annot&
ht be ready to restart discussions on them
;)
WDYT?
-Original Message-
From: Werner Keil [mailto:werner.k...@gmail.com]
Sent: Mittwoch, 3. Dezember 2014 15:25
To: dev@tamaya.incubator.apache.org
Subject: Re: "annotation" instead of "annot"
See DeviceMap that'
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;
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 :
> Well, th
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
wrote:
> if we
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.co
+1 for full names wherever possible and the norm.
On Wed Dec 03 2014 at 8:54:58 AM Andres Almiray wrote:
> +1 on "annotation"
>
> ---
> Java Champion; Groovy Enthusiast
> http://jroller.com/aalmiray
> http://www.linkedin.com/in/aalmiray
> --
> What goes up
+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
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.
A
71 matches
Mail list logo
