You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Mark Struberg <st...@yahoo.de> on 2016/07/14 22:10:45 UTC
Configuration for Java SE and Java EE JSR
Hi folks!
I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
My goal is to establish an own JSR for configuration.
So far it consists of 2 classes for the API and 4 classes for the SPI.
The source can be found here.
https://github.com/struberg/javaConfig
And that’s pretty much it! There is not much more needed for it.
I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
wdyt?
LieGrue,
strub
Re: Configuration for Java SE and Java EE JSR
Posted by Alan Cabrera <li...@toolazydogs.com>.
Can we have a weekend moratorium on this thread so we call all cool off?
I’d like to toss out some important points to consider over the weekend.
TL;DR:
it’s ok for there to be multiple ASF projects that accomplish the exact same thing
any competent person is welcome to join any ASF project
the Apache Software Foundation, itself, does not submit JSRs
It’s ok for there to be multiple ASF projects that accomplish the exact same thing
There is no land grab of ideas or product spaces here at the ASF. If a bunch of people I wanted to implement a map/reduce system we could. The fact that Apache Hadoop is in existence shouldn’t be a barrier. I’ll go even further and say that because of AL2.0, we could fork bits, or even co-opt huge swaths of code, from Apache Hadoop and use it to our own means. The only criteria the ASF would hold our new project to is that of a healthy vibrant community.
Any competent person is welcome to join any ASF project
Anyone could join our new fictitious project, even Apache Hadoop developers. An interesting result of this is that just because people worked on Apache Hadoop, they are not married to Apache Hadoop. They are not traitors if they decide to also dabble in our new project. So long as there are healthy vibrant communities on both sides, e.g. interactions are done in a respectful manner, it’s all good in the eyes of the ASF.
The Apache Software Foundation, itself, does not incubate/submit JSRs
The protocol etiquette of submitting a JSR is, thankfully, the JCP’s headache and such discussions should take place outside of the ASF project mailing lists. Also, just because a project is a part of the ASF does not ensure that it will be a viable JSR. Being an ASF project does not imply that the ASF explicitly or implicitly endorses it as a JSR contender. IMHO, it may be a bit premature to submit a JSR for this problem domain; jm2c.
Regards,
Alan
> On Jul 14, 2016, at 3:10 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
Re: Configuration for Java SE and Java EE JSR
Posted by Alan Cabrera <li...@toolazydogs.com>.
You’re welcome to ticker around w/ configuration with the Geronimo JEE pantheon.
Tamaya developers are welcome ticker around w/ configuration with the Geronimo JEE pantheon.
It’s ok if Geronimo has two, or even more, different configuration mechanisms. I predict that the config adapter to accommodate the two would be pretty damn interesting, especially if it were a result of collaboration between Tamaya developers and your team, Mark.
I will explicitly point out, as I’ve said in other emails on this topic, discussions of JSR/JCP have no place on these mailing lists, usually.
With that said, how can we help? I know that we need to pull off the dust covers of a lot of our tooling. I’m generating an inventory of what’s fallen into disrepair.
Regards,
Alan
> On Jul 14, 2016, at 3:10 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
Re: Configuration for Java SE and Java EE JSR
Posted by Alan Cabrera <li...@toolazydogs.com>.
You’re welcome to ticker around w/ configuration with the Geronimo JEE pantheon.
Tamaya developers are welcome ticker around w/ configuration with the Geronimo JEE pantheon.
It’s ok if Geronimo has two, or even more, different configuration mechanisms. I predict that the config adapter to accommodate the two would be pretty damn interesting, especially if it were a result of collaboration between Tamaya developers and your team, Mark.
I will explicitly point out, as I’ve said in other emails on this topic, discussions of JSR/JCP have no place on these mailing lists, usually.
With that said, how can we help? I know that we need to pull off the dust covers of a lot of our tooling. I’m generating an inventory of what’s fallen into disrepair.
Regards,
Alan
> On Jul 14, 2016, at 3:10 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
Re: Configuration for Java SE and Java EE JSR
Posted by Alan Cabrera <li...@toolazydogs.com>.
Can we have a weekend moratorium on this thread so we call all cool off?
I’d like to toss out some important points to consider over the weekend.
TL;DR:
it’s ok for there to be multiple ASF projects that accomplish the exact same thing
any competent person is welcome to join any ASF project
the Apache Software Foundation, itself, does not submit JSRs
It’s ok for there to be multiple ASF projects that accomplish the exact same thing
There is no land grab of ideas or product spaces here at the ASF. If a bunch of people I wanted to implement a map/reduce system we could. The fact that Apache Hadoop is in existence shouldn’t be a barrier. I’ll go even further and say that because of AL2.0, we could fork bits, or even co-opt huge swaths of code, from Apache Hadoop and use it to our own means. The only criteria the ASF would hold our new project to is that of a healthy vibrant community.
Any competent person is welcome to join any ASF project
Anyone could join our new fictitious project, even Apache Hadoop developers. An interesting result of this is that just because people worked on Apache Hadoop, they are not married to Apache Hadoop. They are not traitors if they decide to also dabble in our new project. So long as there are healthy vibrant communities on both sides, e.g. interactions are done in a respectful manner, it’s all good in the eyes of the ASF.
The Apache Software Foundation, itself, does not incubate/submit JSRs
The protocol etiquette of submitting a JSR is, thankfully, the JCP’s headache and such discussions should take place outside of the ASF project mailing lists. Also, just because a project is a part of the ASF does not ensure that it will be a viable JSR. Being an ASF project does not imply that the ASF explicitly or implicitly endorses it as a JSR contender. IMHO, it may be a bit premature to submit a JSR for this problem domain; jm2c.
Regards,
Alan
> On Jul 14, 2016, at 3:10 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Besides from a technical point "Doing this at Geronimo", who would do this
in 2016?
http://geronimo.apache.org/ shows no release or activity for the past 3
years. While TomEE (though it so far aims at the Web profile only, also not
yet Java EE 7 certified) makes a very active and healthy impression. David
isn't only active in several Java EE JSRs Tomitribe together with others
(several major container providers) launched the "Microprofile" idea and
also got Oracle's attention.
Better speak to some of those guys, maybe when the time is right also to
try form an EG, but not try to push your own rogue standard in a
cloak-and-dagger-operation.
Otavio who's also in the Tamaya poddling did this slightly more sensitive.
Though the JNOSQL structure contains module skeletons those seem more like
the idea and preparation towards an Apache Incubator proposal than putting
something like "javax.nosql" there now and all by himself;-)
Although he has not even proposed the Apache project others in the EC
sounded open to the idea, but they probably won't suddently throw out their
idea of "javax.nosql" either;-)
JCache took a very long time and was largely influenced by projects like
EHCache.
If you just take the very top level org.apache.tamaya and maybe
org.apache.tamaya.spi, those packages and very small independent modules
feel like something to look into.
Maybe with other projects or proposals, but until a JSR is formally
approved none of that deserves to call itself "javax.config" or whatever;-)
Cheers,
Werner
Re: Configuration for Java SE and Java EE JSR
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi, I share Anatole's view up to 100%.
Am 15.07.16 um 02:56 schrieb Anatole Tresch:
> Hi all
>
> Folks, calm down a bit. Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being actively
> participating on the project the last months you raise your own initiative
> without involving the other people here.
> 2) That the whole Tamaya project is too bis for a JSR is clear,
> nevertheless the API part may be still small enough (it is smaller than
> the money JSR...). This was clearly stated from the start, just remember
> this.
> 3) That you start your initiative outside of Tamaya, indirectly
> damaging/ignoring the work done so far.
>
> So, please collaborate with the guys here on the project, instead of
> running your own thing. Without joining our forces things probably will not
> be successful at all, which would be huge damage. There is much more
> politics involved that you can ever imagine, ignoring that point is simply
> naive IMO.
>
> And the scope discussion basically is something to be taken within a JSR,
> if we have one running...
>
> Thanks, J
> Anatole
>
>
>
>
> 2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
>
>> It really makes a "People's Front of Judea" or maybe rather say "People's
>> Front of JCP" impression here;-)
>>
>> 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.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Short comments inline...
2016-07-15 16:28 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi all,
>
>
> Am 15.07.16 um 14:42 schrieb Anatole Tresch:
>
>> 1) Do we want to support non String values, including type literals?
>>
> Yes, we need this nowaday. String would work but would never consider a
> framework nowadays where I have to do all this by hand. Other frameworks as
> Spring supports this out of the box.
>
2) Do we want to support mutability? OOTB as part of the Configuration
>> interface, or indirectly, e.g. by applying some kind of Adapter pattern?
>>
> I will have to look at the API to answer this.
>
>> 3) Anything else?
>>
> Please do not start simply now two overhaul the whole core stuff. I try to
> use Tamaya in my projects to get a feeling how it feels to use Tamaya.
> Changing the API now would be not helpful for me at least.
>
-
> That was not my intention. I dont think we need more basically, but I am
open to hear argument, if I should have overseen something...
>
> I will have time to help again with the implementation. I think Phil and
>> Oliver are also motivated, if we we see a good chance to progress with our
>> initiative... ;) So would be great if the other guys could at least join
>> discussions here on the list and actively help directing us to do the
>> right
>> things...
>>
>
> Yes, but we need a better process to define our goals.
>
-> And a clear timeline!
> One thing I'd love once the API will be reviewed is to provide a simple
>>> tomee-embedded-tamaya-server fatjar providing a REST application and a
>>> client "source" to fill the config entries. We would then have a
>>> fullstack
>>> solution ready to use.
>>>
>>
-
> Sounds good!
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Hi Oliver
trying to separate concerns String values are the minimal basics.
Conversion could be added in multiple ways. One very powerful concept is
using method references, e.g.
T get(String key, Function<String,T> conversion);
T getOrDefault(String key, Function<String,T> conversion, T defaultValue);
of even using a *Supplier*:
T getOrDefault(String key, Function<String,T> conversion, Supplier<T>
defaultValueSupplier);
String getOrDefault(String key, Supplier<String> defaultValueSupplier);
Given that we have a clear separation and conversion logic is completely
decoupled, which IMO would be one way to handle that on the low level API
level (Configuration).
BTW: we had lots of discussions about the Java version to be supported. For
a JSR Java 8 must be the base IMO. At least for conversion as above it
brings lots of adventages for implementors, see
https://github.com/apache/incubator-tamaya/blob/tamaya-next/code/api/src/main/java/org/apache/tamaya/Configuration.java
Given that an implementation of Configuration requires only two methods to
be implemented ;):
String get(String key);
Map<String,String> getProperties();
2016-07-15 16:28 GMT+02:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi all,
>
>
> Am 15.07.16 um 14:42 schrieb Anatole Tresch:
>
>> 1) Do we want to support non String values, including type literals?
>>
> Yes, we need this nowaday. String would work but would never consider a
> framework nowadays where I have to do all this by hand. Other frameworks as
> Spring supports this out of the box.
>
>> 2) Do we want to support mutability? OOTB as part of the Configuration
>> interface, or indirectly, e.g. by applying some kind of Adapter pattern?
>>
> I will have to look at the API to answer this.
>
>> 3) Anything else?
>>
> Please do not start simply now two overhaul the whole core stuff. I try to
> use Tamaya in my projects to get a feeling how it feels to use Tamaya.
> Changing the API now would be not helpful for me at least.
>
> I will have time to help again with the implementation. I think Phil and
>> Oliver are also motivated, if we we see a good chance to progress with our
>> initiative... ;) So would be great if the other guys could at least join
>> discussions here on the list and actively help directing us to do the
>> right
>> things...
>>
>> J Anatole
>>
>
> Yes, but we need a better process to define our goals.
>
> Oliver
>
>
>>
>>
>>
>> 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>> To be concrete it means:
>>>
>>> 1. removing auto resolution from tamaya (and provide it through
>>> integration
>>> modules, cdi/spring/guice/OSGi...)
>>> 2. ensure the API is minimal (can be the case, didnt check since few
>>> months
>>> but last time it got considerations which were not relevant IMO cause of
>>> 1
>>> mainly and impl details)
>>>
>>> I sadly can't help much now but hope to be able to join the effort end of
>>> the year (if I don't shout my way, I'll do my best to make it possible
>>> ~october)
>>>
>>> One thing I'd love once the API will be reviewed is to provide a simple
>>> tomee-embedded-tamaya-server fatjar providing a REST application and a
>>> client "source" to fill the config entries. We would then have a
>>> fullstack
>>> solution ready to use.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com> | JavaEE Factory
>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>
>>> 2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
>>>
>>> with
>>> some
>>> whatever
>>> a
>>> much
>>> RI
>>> of
>>> *
>>>
>>
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi all,
Am 15.07.16 um 14:42 schrieb Anatole Tresch:
> 1) Do we want to support non String values, including type literals?
Yes, we need this nowaday. String would work but would never consider a
framework nowadays where I have to do all this by hand. Other frameworks
as Spring supports this out of the box.
> 2) Do we want to support mutability? OOTB as part of the Configuration
> interface, or indirectly, e.g. by applying some kind of Adapter pattern?
I will have to look at the API to answer this.
> 3) Anything else?
Please do not start simply now two overhaul the whole core stuff. I try
to use Tamaya in my projects to get a feeling how it feels to use
Tamaya. Changing the API now would be not helpful for me at least.
> I will have time to help again with the implementation. I think Phil and
> Oliver are also motivated, if we we see a good chance to progress with our
> initiative... ;) So would be great if the other guys could at least join
> discussions here on the list and actively help directing us to do the right
> things...
>
> J Anatole
Yes, but we need a better process to define our goals.
Oliver
>
>
>
>
> 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> To be concrete it means:
>>
>> 1. removing auto resolution from tamaya (and provide it through integration
>> modules, cdi/spring/guice/OSGi...)
>> 2. ensure the API is minimal (can be the case, didnt check since few months
>> but last time it got considerations which were not relevant IMO cause of 1
>> mainly and impl details)
>>
>> I sadly can't help much now but hope to be able to join the effort end of
>> the year (if I don't shout my way, I'll do my best to make it possible
>> ~october)
>>
>> One thing I'd love once the API will be reviewed is to provide a simple
>> tomee-embedded-tamaya-server fatjar providing a REST application and a
>> client "source" to fill the config entries. We would then have a fullstack
>> solution ready to use.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
>>
>> with
>> some
>> whatever
>> a
>> much
>> RI
>> of
>> *
>
>
--
N Oliver B. Fischer
A Sch�nhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
2016-07-15 15:00 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> > 2) Do we want to support mutability? OOTB as part of the Configuration
> > interface, or indirectly, e.g. by applying some kind of Adapter pattern?
>
> Let’s first define what mutability means.
> Any ‚consumer‘ should imo not be able to directly change configured values.
> Of course if a ConfigSource directly reflects changes in it’s underlying
> configuration then it will directly change the overall result (if it is the
> highest ordinal for that key).
> An example would be a custom ‚DatabaseConfigSource‘ which just reads all
> config items from a database table once per minute. If the values in the DB
> change then the ConfigSource will also return those modified values.
>
> At the end I’d say that it’s up to the ConfigSource impl and the
> Configuration API nor the ConfigSources imo should not have any methods to
> modify the underlying values.
>
Agreed. So summarizing this means the API for accesing config is read-only
(as it is of now). That could even mean that we do not care about
mutability from an API perspective, but delegate to the implementations how
ot of they want to support mutability.
I’m available for hacking, hangout, etc
>
Great. Will have to look at my time planning... Oli? How is it looking on
your side?
> LieGrue,
> strub
>
>
> > Am 15.07.2016 um 14:42 schrieb Anatole Tresch <at...@gmail.com>:
> >
> > Hi Romain/all
> >
> > sounds good. I started already shortly a branch and removed much things:
> >
> >
> https://github.com/apache/incubator-tamaya/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
> >
> > The point about resolution is not yet done. I would suggest focusing our
> > discussions first on the Configuration class:
> >
> > 1) Do we want to support non String values, including type literals?
> > 2) Do we want to support mutability? OOTB as part of the Configuration
> > interface, or indirectly, e.g. by applying some kind of Adapter pattern?
> > 3) Anything else?
> >
> > I will have time to help again with the implementation. I think Phil and
> > Oliver are also motivated, if we we see a good chance to progress with
> our
> > initiative... ;) So would be great if the other guys could at least join
> > discussions here on the list and actively help directing us to do the
> right
> > things...
> >
> > J Anatole
> >
> >
> >
> >
> >
> > 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >
> >> To be concrete it means:
> >>
> >> 1. removing auto resolution from tamaya (and provide it through
> integration
> >> modules, cdi/spring/guice/OSGi...)
> >> 2. ensure the API is minimal (can be the case, didnt check since few
> months
> >> but last time it got considerations which were not relevant IMO cause
> of 1
> >> mainly and impl details)
> >>
> >> I sadly can't help much now but hope to be able to join the effort end
> of
> >> the year (if I don't shout my way, I'll do my best to make it possible
> >> ~october)
> >>
> >> One thing I'd love once the API will be reviewed is to provide a simple
> >> tomee-embedded-tamaya-server fatjar providing a REST application and a
> >> client "source" to fill the config entries. We would then have a
> fullstack
> >> solution ready to use.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> <http://www.tomitribe.com> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> >>
> >>> Not sure, if I get all (from a language perspective), but overall I
> think
> >>> we may be on the same page...
> >>>
> >>> 2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >>>
> >>>> 2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> >>>>
> >>>>> Yep ;). IMO we need
> >>>>>
> >>>>> - *ConfigurationProvider* (basically only for being compatible
> >> with
> >>>> Java
> >>>>> 7, with Java 8 we can use a static method on the *Configuration*
> >>>>> interface), which serves as an singleton access point for
> >>>>> *Configuration*.
> >>>>>
> >>>>> - We might further (re)discuss the feature set provided by
> >>>>> *Configuration* (interface).
> >>>>> - Finally the *Configuration* used actually must be resolved by
> >> some
> >>>> SPI
> >>>>> defined by the ConfigurationProvider.
> >>>>>
> >>>>>
> >>>> That's my main issue ATM, the resolution
> >>>>
> >>>> I'd see the config "solution/JSR" to provide a way to configure a
> >>>> Configuration instance (can be with annotation for CDI or whatever but
> >>>> finally it builds a Configuration) then let the framework you
> integrate
> >>>> with (CDI if we continue previous example) to contextualize it.
> >>>>
> >>>> What does it mean?
> >>>>
> >>>> - it will work with spring/guice/standalone/cdi/OSGi
> >>>> - you can configure multiple configurations
> >>>> - you never hit a "key" issue on the config side and delegates this
> >>> problem
> >>>> to the framework you work with which already solved it which will
> avoid
> >>> to
> >>>> mix resolution between frameworks
> >>>>
> >>>>
> >>>>> That's it. All the other stuff we have currently in the SPI could be
> >>>> moved
> >>>>> outside, e.g. to the builder module. This way we get a super simple
> >>> API,
> >>>>> just serving config and no more. We can delegate completely to
> >> whatever
> >>>>> backend we want to use, including externalizing everything to Consul
> >>> or a
> >>>>> simple properties file or whatever is appropriate.
> >>>>>
> >>>>> We can use ServiceLoader/@Priority for selecting the right
> >>> Configuration
> >>>>> instance, possibly overridable by a system property.
> >>>>>
> >>>>> We should also also shortly discuss on mutability of configuration.
> >>>>>
> >>>>> That would be what I think is minimal... (I guess depending on the
> >>>> outcome
> >>>>> we should have no more than 10 artifacts overall) is that a base for
> >>>>> discussion? I would then create a discussion branch and put together
> >> a
> >>>>> small proposal unless somebody else wants to do that.
> >>>>>
> >>>>> I think with such a small proposal we have a good chance to start
> >>>>> discussions also with the JCP ;)
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> J Anatole
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2016-07-15 11:16 GMT+02:00 Mark Struberg <struberg@yahoo.de.invalid
> >>> :
> >>>>>
> >>>>>>
> >>>>>>> Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com
> >>>>>>> :
> >>>>>>>
> >>>>>>> @Anatole: think we communicated about the design choice we don't
> >>> like
> >>>>> in
> >>>>>> tamaya and answer was "you are alone" IIRC but let's try to review
> >>> some
> >>>>> of
> >>>>>> them now maybe
> >>>>>>>
> >>>>>>
> >>>>>> Well, actually it was you, Gerhard, Reinhard and me who wanted a
> >> much
> >>>>>> smaller and cleaner API.
> >>>>>>
> >>>>>> Probably a possibly solution would be to have a part which is
> >>>> explicitly
> >>>>>> devoted for a JSR candidate. Only the most important parts. API +
> >> RI
> >>> +
> >>>>> spec
> >>>>>> + TCK.
> >>>>>>
> >>>>>> And then there is another API which then adds all the icing on top
> >> of
> >>>> it?
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *Anatole Tresch*
> >>>>> PPMC Member Apache Tamaya
> >>>>> JCP Star Spec Lead
> >>>>> *Switzerland, Europe Zurich, GMT+1*
> >>>>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/>
> >> *
> >>>>> *Twitter: @atsticks, @tamayaconf*
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> *Anatole Tresch*
> >>> PPMC Member Apache Tamaya
> >>> JCP Star Spec Lead
> >>> *Switzerland, Europe Zurich, GMT+1*
> >>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> >>> *Twitter: @atsticks, @tamayaconf*
> >>>
> >>
> >
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > *Twitter: @atsticks, @tamayaconf*
>
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> 1) Do we want to support non String values, including type literals?
For the bare basic I’d say no. If you have the String representation you can still convert it to any other Type in an outer layer.
> 2) Do we want to support mutability? OOTB as part of the Configuration
> interface, or indirectly, e.g. by applying some kind of Adapter pattern?
Let’s first define what mutability means.
Any ‚consumer‘ should imo not be able to directly change configured values.
Of course if a ConfigSource directly reflects changes in it’s underlying configuration then it will directly change the overall result (if it is the highest ordinal for that key).
An example would be a custom ‚DatabaseConfigSource‘ which just reads all config items from a database table once per minute. If the values in the DB change then the ConfigSource will also return those modified values.
At the end I’d say that it’s up to the ConfigSource impl and the Configuration API nor the ConfigSources imo should not have any methods to modify the underlying values.
I’m available for hacking, hangout, etc
LieGrue,
strub
> Am 15.07.2016 um 14:42 schrieb Anatole Tresch <at...@gmail.com>:
>
> Hi Romain/all
>
> sounds good. I started already shortly a branch and removed much things:
>
> https://github.com/apache/incubator-tamaya/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
>
> The point about resolution is not yet done. I would suggest focusing our
> discussions first on the Configuration class:
>
> 1) Do we want to support non String values, including type literals?
> 2) Do we want to support mutability? OOTB as part of the Configuration
> interface, or indirectly, e.g. by applying some kind of Adapter pattern?
> 3) Anything else?
>
> I will have time to help again with the implementation. I think Phil and
> Oliver are also motivated, if we we see a good chance to progress with our
> initiative... ;) So would be great if the other guys could at least join
> discussions here on the list and actively help directing us to do the right
> things...
>
> J Anatole
>
>
>
>
>
> 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> To be concrete it means:
>>
>> 1. removing auto resolution from tamaya (and provide it through integration
>> modules, cdi/spring/guice/OSGi...)
>> 2. ensure the API is minimal (can be the case, didnt check since few months
>> but last time it got considerations which were not relevant IMO cause of 1
>> mainly and impl details)
>>
>> I sadly can't help much now but hope to be able to join the effort end of
>> the year (if I don't shout my way, I'll do my best to make it possible
>> ~october)
>>
>> One thing I'd love once the API will be reviewed is to provide a simple
>> tomee-embedded-tamaya-server fatjar providing a REST application and a
>> client "source" to fill the config entries. We would then have a fullstack
>> solution ready to use.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
>>
>>> Not sure, if I get all (from a language perspective), but overall I think
>>> we may be on the same page...
>>>
>>> 2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>>>
>>>> 2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
>>>>
>>>>> Yep ;). IMO we need
>>>>>
>>>>> - *ConfigurationProvider* (basically only for being compatible
>> with
>>>> Java
>>>>> 7, with Java 8 we can use a static method on the *Configuration*
>>>>> interface), which serves as an singleton access point for
>>>>> *Configuration*.
>>>>>
>>>>> - We might further (re)discuss the feature set provided by
>>>>> *Configuration* (interface).
>>>>> - Finally the *Configuration* used actually must be resolved by
>> some
>>>> SPI
>>>>> defined by the ConfigurationProvider.
>>>>>
>>>>>
>>>> That's my main issue ATM, the resolution
>>>>
>>>> I'd see the config "solution/JSR" to provide a way to configure a
>>>> Configuration instance (can be with annotation for CDI or whatever but
>>>> finally it builds a Configuration) then let the framework you integrate
>>>> with (CDI if we continue previous example) to contextualize it.
>>>>
>>>> What does it mean?
>>>>
>>>> - it will work with spring/guice/standalone/cdi/OSGi
>>>> - you can configure multiple configurations
>>>> - you never hit a "key" issue on the config side and delegates this
>>> problem
>>>> to the framework you work with which already solved it which will avoid
>>> to
>>>> mix resolution between frameworks
>>>>
>>>>
>>>>> That's it. All the other stuff we have currently in the SPI could be
>>>> moved
>>>>> outside, e.g. to the builder module. This way we get a super simple
>>> API,
>>>>> just serving config and no more. We can delegate completely to
>> whatever
>>>>> backend we want to use, including externalizing everything to Consul
>>> or a
>>>>> simple properties file or whatever is appropriate.
>>>>>
>>>>> We can use ServiceLoader/@Priority for selecting the right
>>> Configuration
>>>>> instance, possibly overridable by a system property.
>>>>>
>>>>> We should also also shortly discuss on mutability of configuration.
>>>>>
>>>>> That would be what I think is minimal... (I guess depending on the
>>>> outcome
>>>>> we should have no more than 10 artifacts overall) is that a base for
>>>>> discussion? I would then create a discussion branch and put together
>> a
>>>>> small proposal unless somebody else wants to do that.
>>>>>
>>>>> I think with such a small proposal we have a good chance to start
>>>>> discussions also with the JCP ;)
>>>>>
>>>>> WDYT?
>>>>>
>>>>> J Anatole
>>>>>
>>>>>
>>>>>
>>>>> 2016-07-15 11:16 GMT+02:00 Mark Struberg <struberg@yahoo.de.invalid
>>> :
>>>>>
>>>>>>
>>>>>>> Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com
>>>>>>> :
>>>>>>>
>>>>>>> @Anatole: think we communicated about the design choice we don't
>>> like
>>>>> in
>>>>>> tamaya and answer was "you are alone" IIRC but let's try to review
>>> some
>>>>> of
>>>>>> them now maybe
>>>>>>>
>>>>>>
>>>>>> Well, actually it was you, Gerhard, Reinhard and me who wanted a
>> much
>>>>>> smaller and cleaner API.
>>>>>>
>>>>>> Probably a possibly solution would be to have a part which is
>>>> explicitly
>>>>>> devoted for a JSR candidate. Only the most important parts. API +
>> RI
>>> +
>>>>> spec
>>>>>> + TCK.
>>>>>>
>>>>>> And then there is another API which then adds all the icing on top
>> of
>>>> it?
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Anatole Tresch*
>>>>> PPMC Member Apache Tamaya
>>>>> JCP Star Spec Lead
>>>>> *Switzerland, Europe Zurich, GMT+1*
>>>>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/>
>> *
>>>>> *Twitter: @atsticks, @tamayaconf*
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> *Anatole Tresch*
>>> PPMC Member Apache Tamaya
>>> JCP Star Spec Lead
>>> *Switzerland, Europe Zurich, GMT+1*
>>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
>>> *Twitter: @atsticks, @tamayaconf*
>>>
>>
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
sounds great Anatole,
don't hesitate to ping me if I miss one of these topic, would be happy to
participate to these dicussions
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-15 14:42 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> Hi Romain/all
>
> sounds good. I started already shortly a branch and removed much things:
>
>
> https://github.com/apache/incubator-tamaya/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
>
> The point about resolution is not yet done. I would suggest focusing our
> discussions first on the Configuration class:
>
> 1) Do we want to support non String values, including type literals?
> 2) Do we want to support mutability? OOTB as part of the Configuration
> interface, or indirectly, e.g. by applying some kind of Adapter pattern?
> 3) Anything else?
>
> I will have time to help again with the implementation. I think Phil and
> Oliver are also motivated, if we we see a good chance to progress with our
> initiative... ;) So would be great if the other guys could at least join
> discussions here on the list and actively help directing us to do the right
> things...
>
> J Anatole
>
>
>
>
>
> 2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> > To be concrete it means:
> >
> > 1. removing auto resolution from tamaya (and provide it through
> integration
> > modules, cdi/spring/guice/OSGi...)
> > 2. ensure the API is minimal (can be the case, didnt check since few
> months
> > but last time it got considerations which were not relevant IMO cause of
> 1
> > mainly and impl details)
> >
> > I sadly can't help much now but hope to be able to join the effort end of
> > the year (if I don't shout my way, I'll do my best to make it possible
> > ~october)
> >
> > One thing I'd love once the API will be reviewed is to provide a simple
> > tomee-embedded-tamaya-server fatjar providing a REST application and a
> > client "source" to fill the config entries. We would then have a
> fullstack
> > solution ready to use.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> >
> > > Not sure, if I get all (from a language perspective), but overall I
> think
> > > we may be on the same page...
> > >
> > > 2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> > >
> > > > 2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> > > >
> > > > > Yep ;). IMO we need
> > > > >
> > > > > - *ConfigurationProvider* (basically only for being compatible
> > with
> > > > Java
> > > > > 7, with Java 8 we can use a static method on the *Configuration*
> > > > > interface), which serves as an singleton access point for
> > > > > *Configuration*.
> > > > >
> > > > > - We might further (re)discuss the feature set provided by
> > > > > *Configuration* (interface).
> > > > > - Finally the *Configuration* used actually must be resolved by
> > some
> > > > SPI
> > > > > defined by the ConfigurationProvider.
> > > > >
> > > > >
> > > > That's my main issue ATM, the resolution
> > > >
> > > > I'd see the config "solution/JSR" to provide a way to configure a
> > > > Configuration instance (can be with annotation for CDI or whatever
> but
> > > > finally it builds a Configuration) then let the framework you
> integrate
> > > > with (CDI if we continue previous example) to contextualize it.
> > > >
> > > > What does it mean?
> > > >
> > > > - it will work with spring/guice/standalone/cdi/OSGi
> > > > - you can configure multiple configurations
> > > > - you never hit a "key" issue on the config side and delegates this
> > > problem
> > > > to the framework you work with which already solved it which will
> avoid
> > > to
> > > > mix resolution between frameworks
> > > >
> > > >
> > > > > That's it. All the other stuff we have currently in the SPI could
> be
> > > > moved
> > > > > outside, e.g. to the builder module. This way we get a super simple
> > > API,
> > > > > just serving config and no more. We can delegate completely to
> > whatever
> > > > > backend we want to use, including externalizing everything to
> Consul
> > > or a
> > > > > simple properties file or whatever is appropriate.
> > > > >
> > > > > We can use ServiceLoader/@Priority for selecting the right
> > > Configuration
> > > > > instance, possibly overridable by a system property.
> > > > >
> > > > > We should also also shortly discuss on mutability of configuration.
> > > > >
> > > > > That would be what I think is minimal... (I guess depending on the
> > > > outcome
> > > > > we should have no more than 10 artifacts overall) is that a base
> for
> > > > > discussion? I would then create a discussion branch and put
> together
> > a
> > > > > small proposal unless somebody else wants to do that.
> > > > >
> > > > > I think with such a small proposal we have a good chance to start
> > > > > discussions also with the JCP ;)
> > > > >
> > > > > WDYT?
> > > > >
> > > > > J Anatole
> > > > >
> > > > >
> > > > >
> > > > > 2016-07-15 11:16 GMT+02:00 Mark Struberg <struberg@yahoo.de.invalid
> > >:
> > > > >
> > > > > >
> > > > > > > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > @Anatole: think we communicated about the design choice we
> don't
> > > like
> > > > > in
> > > > > > tamaya and answer was "you are alone" IIRC but let's try to
> review
> > > some
> > > > > of
> > > > > > them now maybe
> > > > > > >
> > > > > >
> > > > > > Well, actually it was you, Gerhard, Reinhard and me who wanted a
> > much
> > > > > > smaller and cleaner API.
> > > > > >
> > > > > > Probably a possibly solution would be to have a part which is
> > > > explicitly
> > > > > > devoted for a JSR candidate. Only the most important parts. API +
> > RI
> > > +
> > > > > spec
> > > > > > + TCK.
> > > > > >
> > > > > > And then there is another API which then adds all the icing on
> top
> > of
> > > > it?
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Anatole Tresch*
> > > > > PPMC Member Apache Tamaya
> > > > > JCP Star Spec Lead
> > > > > *Switzerland, Europe Zurich, GMT+1*
> > > > > *maketechsimple.wordpress.com <
> http://maketechsimple.wordpress.com/>
> > *
> > > > > *Twitter: @atsticks, @tamayaconf*
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Anatole Tresch*
> > > PPMC Member Apache Tamaya
> > > JCP Star Spec Lead
> > > *Switzerland, Europe Zurich, GMT+1*
> > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > > *Twitter: @atsticks, @tamayaconf*
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Hi Romain/all
sounds good. I started already shortly a branch and removed much things:
https://github.com/apache/incubator-tamaya/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
The point about resolution is not yet done. I would suggest focusing our
discussions first on the Configuration class:
1) Do we want to support non String values, including type literals?
2) Do we want to support mutability? OOTB as part of the Configuration
interface, or indirectly, e.g. by applying some kind of Adapter pattern?
3) Anything else?
I will have time to help again with the implementation. I think Phil and
Oliver are also motivated, if we we see a good chance to progress with our
initiative... ;) So would be great if the other guys could at least join
discussions here on the list and actively help directing us to do the right
things...
J Anatole
2016-07-15 14:09 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> To be concrete it means:
>
> 1. removing auto resolution from tamaya (and provide it through integration
> modules, cdi/spring/guice/OSGi...)
> 2. ensure the API is minimal (can be the case, didnt check since few months
> but last time it got considerations which were not relevant IMO cause of 1
> mainly and impl details)
>
> I sadly can't help much now but hope to be able to join the effort end of
> the year (if I don't shout my way, I'll do my best to make it possible
> ~october)
>
> One thing I'd love once the API will be reviewed is to provide a simple
> tomee-embedded-tamaya-server fatjar providing a REST application and a
> client "source" to fill the config entries. We would then have a fullstack
> solution ready to use.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
>
> > Not sure, if I get all (from a language perspective), but overall I think
> > we may be on the same page...
> >
> > 2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> >
> > > 2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> > >
> > > > Yep ;). IMO we need
> > > >
> > > > - *ConfigurationProvider* (basically only for being compatible
> with
> > > Java
> > > > 7, with Java 8 we can use a static method on the *Configuration*
> > > > interface), which serves as an singleton access point for
> > > > *Configuration*.
> > > >
> > > > - We might further (re)discuss the feature set provided by
> > > > *Configuration* (interface).
> > > > - Finally the *Configuration* used actually must be resolved by
> some
> > > SPI
> > > > defined by the ConfigurationProvider.
> > > >
> > > >
> > > That's my main issue ATM, the resolution
> > >
> > > I'd see the config "solution/JSR" to provide a way to configure a
> > > Configuration instance (can be with annotation for CDI or whatever but
> > > finally it builds a Configuration) then let the framework you integrate
> > > with (CDI if we continue previous example) to contextualize it.
> > >
> > > What does it mean?
> > >
> > > - it will work with spring/guice/standalone/cdi/OSGi
> > > - you can configure multiple configurations
> > > - you never hit a "key" issue on the config side and delegates this
> > problem
> > > to the framework you work with which already solved it which will avoid
> > to
> > > mix resolution between frameworks
> > >
> > >
> > > > That's it. All the other stuff we have currently in the SPI could be
> > > moved
> > > > outside, e.g. to the builder module. This way we get a super simple
> > API,
> > > > just serving config and no more. We can delegate completely to
> whatever
> > > > backend we want to use, including externalizing everything to Consul
> > or a
> > > > simple properties file or whatever is appropriate.
> > > >
> > > > We can use ServiceLoader/@Priority for selecting the right
> > Configuration
> > > > instance, possibly overridable by a system property.
> > > >
> > > > We should also also shortly discuss on mutability of configuration.
> > > >
> > > > That would be what I think is minimal... (I guess depending on the
> > > outcome
> > > > we should have no more than 10 artifacts overall) is that a base for
> > > > discussion? I would then create a discussion branch and put together
> a
> > > > small proposal unless somebody else wants to do that.
> > > >
> > > > I think with such a small proposal we have a good chance to start
> > > > discussions also with the JCP ;)
> > > >
> > > > WDYT?
> > > >
> > > > J Anatole
> > > >
> > > >
> > > >
> > > > 2016-07-15 11:16 GMT+02:00 Mark Struberg <struberg@yahoo.de.invalid
> >:
> > > >
> > > > >
> > > > > > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >:
> > > > > >
> > > > > > @Anatole: think we communicated about the design choice we don't
> > like
> > > > in
> > > > > tamaya and answer was "you are alone" IIRC but let's try to review
> > some
> > > > of
> > > > > them now maybe
> > > > > >
> > > > >
> > > > > Well, actually it was you, Gerhard, Reinhard and me who wanted a
> much
> > > > > smaller and cleaner API.
> > > > >
> > > > > Probably a possibly solution would be to have a part which is
> > > explicitly
> > > > > devoted for a JSR candidate. Only the most important parts. API +
> RI
> > +
> > > > spec
> > > > > + TCK.
> > > > >
> > > > > And then there is another API which then adds all the icing on top
> of
> > > it?
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Anatole Tresch*
> > > > PPMC Member Apache Tamaya
> > > > JCP Star Spec Lead
> > > > *Switzerland, Europe Zurich, GMT+1*
> > > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/>
> *
> > > > *Twitter: @atsticks, @tamayaconf*
> > > >
> > >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > *Twitter: @atsticks, @tamayaconf*
> >
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
To be concrete it means:
1. removing auto resolution from tamaya (and provide it through integration
modules, cdi/spring/guice/OSGi...)
2. ensure the API is minimal (can be the case, didnt check since few months
but last time it got considerations which were not relevant IMO cause of 1
mainly and impl details)
I sadly can't help much now but hope to be able to join the effort end of
the year (if I don't shout my way, I'll do my best to make it possible
~october)
One thing I'd love once the API will be reviewed is to provide a simple
tomee-embedded-tamaya-server fatjar providing a REST application and a
client "source" to fill the config entries. We would then have a fullstack
solution ready to use.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-15 13:02 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> Not sure, if I get all (from a language perspective), but overall I think
> we may be on the same page...
>
> 2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> > 2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> >
> > > Yep ;). IMO we need
> > >
> > > - *ConfigurationProvider* (basically only for being compatible with
> > Java
> > > 7, with Java 8 we can use a static method on the *Configuration*
> > > interface), which serves as an singleton access point for
> > > *Configuration*.
> > >
> > > - We might further (re)discuss the feature set provided by
> > > *Configuration* (interface).
> > > - Finally the *Configuration* used actually must be resolved by some
> > SPI
> > > defined by the ConfigurationProvider.
> > >
> > >
> > That's my main issue ATM, the resolution
> >
> > I'd see the config "solution/JSR" to provide a way to configure a
> > Configuration instance (can be with annotation for CDI or whatever but
> > finally it builds a Configuration) then let the framework you integrate
> > with (CDI if we continue previous example) to contextualize it.
> >
> > What does it mean?
> >
> > - it will work with spring/guice/standalone/cdi/OSGi
> > - you can configure multiple configurations
> > - you never hit a "key" issue on the config side and delegates this
> problem
> > to the framework you work with which already solved it which will avoid
> to
> > mix resolution between frameworks
> >
> >
> > > That's it. All the other stuff we have currently in the SPI could be
> > moved
> > > outside, e.g. to the builder module. This way we get a super simple
> API,
> > > just serving config and no more. We can delegate completely to whatever
> > > backend we want to use, including externalizing everything to Consul
> or a
> > > simple properties file or whatever is appropriate.
> > >
> > > We can use ServiceLoader/@Priority for selecting the right
> Configuration
> > > instance, possibly overridable by a system property.
> > >
> > > We should also also shortly discuss on mutability of configuration.
> > >
> > > That would be what I think is minimal... (I guess depending on the
> > outcome
> > > we should have no more than 10 artifacts overall) is that a base for
> > > discussion? I would then create a discussion branch and put together a
> > > small proposal unless somebody else wants to do that.
> > >
> > > I think with such a small proposal we have a good chance to start
> > > discussions also with the JCP ;)
> > >
> > > WDYT?
> > >
> > > J Anatole
> > >
> > >
> > >
> > > 2016-07-15 11:16 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> > >
> > > >
> > > > > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >:
> > > > >
> > > > > @Anatole: think we communicated about the design choice we don't
> like
> > > in
> > > > tamaya and answer was "you are alone" IIRC but let's try to review
> some
> > > of
> > > > them now maybe
> > > > >
> > > >
> > > > Well, actually it was you, Gerhard, Reinhard and me who wanted a much
> > > > smaller and cleaner API.
> > > >
> > > > Probably a possibly solution would be to have a part which is
> > explicitly
> > > > devoted for a JSR candidate. Only the most important parts. API + RI
> +
> > > spec
> > > > + TCK.
> > > >
> > > > And then there is another API which then adds all the icing on top of
> > it?
> > > >
> > > > LieGrue,
> > > > strub
> > >
> > >
> > >
> > >
> > > --
> > > *Anatole Tresch*
> > > PPMC Member Apache Tamaya
> > > JCP Star Spec Lead
> > > *Switzerland, Europe Zurich, GMT+1*
> > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > > *Twitter: @atsticks, @tamayaconf*
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Not sure, if I get all (from a language perspective), but overall I think
we may be on the same page...
2016-07-15 12:33 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> 2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
>
> > Yep ;). IMO we need
> >
> > - *ConfigurationProvider* (basically only for being compatible with
> Java
> > 7, with Java 8 we can use a static method on the *Configuration*
> > interface), which serves as an singleton access point for
> > *Configuration*.
> >
> > - We might further (re)discuss the feature set provided by
> > *Configuration* (interface).
> > - Finally the *Configuration* used actually must be resolved by some
> SPI
> > defined by the ConfigurationProvider.
> >
> >
> That's my main issue ATM, the resolution
>
> I'd see the config "solution/JSR" to provide a way to configure a
> Configuration instance (can be with annotation for CDI or whatever but
> finally it builds a Configuration) then let the framework you integrate
> with (CDI if we continue previous example) to contextualize it.
>
> What does it mean?
>
> - it will work with spring/guice/standalone/cdi/OSGi
> - you can configure multiple configurations
> - you never hit a "key" issue on the config side and delegates this problem
> to the framework you work with which already solved it which will avoid to
> mix resolution between frameworks
>
>
> > That's it. All the other stuff we have currently in the SPI could be
> moved
> > outside, e.g. to the builder module. This way we get a super simple API,
> > just serving config and no more. We can delegate completely to whatever
> > backend we want to use, including externalizing everything to Consul or a
> > simple properties file or whatever is appropriate.
> >
> > We can use ServiceLoader/@Priority for selecting the right Configuration
> > instance, possibly overridable by a system property.
> >
> > We should also also shortly discuss on mutability of configuration.
> >
> > That would be what I think is minimal... (I guess depending on the
> outcome
> > we should have no more than 10 artifacts overall) is that a base for
> > discussion? I would then create a discussion branch and put together a
> > small proposal unless somebody else wants to do that.
> >
> > I think with such a small proposal we have a good chance to start
> > discussions also with the JCP ;)
> >
> > WDYT?
> >
> > J Anatole
> >
> >
> >
> > 2016-07-15 11:16 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> >
> > >
> > > > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >:
> > > >
> > > > @Anatole: think we communicated about the design choice we don't like
> > in
> > > tamaya and answer was "you are alone" IIRC but let's try to review some
> > of
> > > them now maybe
> > > >
> > >
> > > Well, actually it was you, Gerhard, Reinhard and me who wanted a much
> > > smaller and cleaner API.
> > >
> > > Probably a possibly solution would be to have a part which is
> explicitly
> > > devoted for a JSR candidate. Only the most important parts. API + RI +
> > spec
> > > + TCK.
> > >
> > > And then there is another API which then adds all the icing on top of
> it?
> > >
> > > LieGrue,
> > > strub
> >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> > *Twitter: @atsticks, @tamayaconf*
> >
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-07-15 12:06 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> Yep ;). IMO we need
>
> - *ConfigurationProvider* (basically only for being compatible with Java
> 7, with Java 8 we can use a static method on the *Configuration*
> interface), which serves as an singleton access point for
> *Configuration*.
>
> - We might further (re)discuss the feature set provided by
> *Configuration* (interface).
> - Finally the *Configuration* used actually must be resolved by some SPI
> defined by the ConfigurationProvider.
>
>
That's my main issue ATM, the resolution
I'd see the config "solution/JSR" to provide a way to configure a
Configuration instance (can be with annotation for CDI or whatever but
finally it builds a Configuration) then let the framework you integrate
with (CDI if we continue previous example) to contextualize it.
What does it mean?
- it will work with spring/guice/standalone/cdi/OSGi
- you can configure multiple configurations
- you never hit a "key" issue on the config side and delegates this problem
to the framework you work with which already solved it which will avoid to
mix resolution between frameworks
> That's it. All the other stuff we have currently in the SPI could be moved
> outside, e.g. to the builder module. This way we get a super simple API,
> just serving config and no more. We can delegate completely to whatever
> backend we want to use, including externalizing everything to Consul or a
> simple properties file or whatever is appropriate.
>
> We can use ServiceLoader/@Priority for selecting the right Configuration
> instance, possibly overridable by a system property.
>
> We should also also shortly discuss on mutability of configuration.
>
> That would be what I think is minimal... (I guess depending on the outcome
> we should have no more than 10 artifacts overall) is that a base for
> discussion? I would then create a discussion branch and put together a
> small proposal unless somebody else wants to do that.
>
> I think with such a small proposal we have a good chance to start
> discussions also with the JCP ;)
>
> WDYT?
>
> J Anatole
>
>
>
> 2016-07-15 11:16 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
> >
> > > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > >
> > > @Anatole: think we communicated about the design choice we don't like
> in
> > tamaya and answer was "you are alone" IIRC but let's try to review some
> of
> > them now maybe
> > >
> >
> > Well, actually it was you, Gerhard, Reinhard and me who wanted a much
> > smaller and cleaner API.
> >
> > Probably a possibly solution would be to have a part which is explicitly
> > devoted for a JSR candidate. Only the most important parts. API + RI +
> spec
> > + TCK.
> >
> > And then there is another API which then adds all the icing on top of it?
> >
> > LieGrue,
> > strub
>
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Yep ;). IMO we need
- *ConfigurationProvider* (basically only for being compatible with Java
7, with Java 8 we can use a static method on the *Configuration*
interface), which serves as an singleton access point for *Configuration*.
- We might further (re)discuss the feature set provided by
*Configuration* (interface).
- Finally the *Configuration* used actually must be resolved by some SPI
defined by the ConfigurationProvider.
That's it. All the other stuff we have currently in the SPI could be moved
outside, e.g. to the builder module. This way we get a super simple API,
just serving config and no more. We can delegate completely to whatever
backend we want to use, including externalizing everything to Consul or a
simple properties file or whatever is appropriate.
We can use ServiceLoader/@Priority for selecting the right Configuration
instance, possibly overridable by a system property.
We should also also shortly discuss on mutability of configuration.
That would be what I think is minimal... (I guess depending on the outcome
we should have no more than 10 artifacts overall) is that a base for
discussion? I would then create a discussion branch and put together a
small proposal unless somebody else wants to do that.
I think with such a small proposal we have a good chance to start
discussions also with the JCP ;)
WDYT?
J Anatole
2016-07-15 11:16 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
> > Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > @Anatole: think we communicated about the design choice we don't like in
> tamaya and answer was "you are alone" IIRC but let's try to review some of
> them now maybe
> >
>
> Well, actually it was you, Gerhard, Reinhard and me who wanted a much
> smaller and cleaner API.
>
> Probably a possibly solution would be to have a part which is explicitly
> devoted for a JSR candidate. Only the most important parts. API + RI + spec
> + TCK.
>
> And then there is another API which then adds all the icing on top of it?
>
> LieGrue,
> strub
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> Am 15.07.2016 um 09:31 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> @Anatole: think we communicated about the design choice we don't like in tamaya and answer was "you are alone" IIRC but let's try to review some of them now maybe
>
Well, actually it was you, Gerhard, Reinhard and me who wanted a much smaller and cleaner API.
Probably a possibly solution would be to have a part which is explicitly devoted for a JSR candidate. Only the most important parts. API + RI + spec + TCK.
And then there is another API which then adds all the icing on top of it?
LieGrue,
strub
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Anatole: think we communicated about the design choice we don't like in
tamaya and answer was "you are alone" IIRC but let's try to review some of
them now maybe
2016-07-15 2:56 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> Hi all
>
> Folks, calm down a bit. Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being
> actively participating on the project the last months you raise your own
> initiative without involving the other people here.
> 2) That the whole Tamaya project is too bis for a JSR is clear,
> nevertheless the API part may be still small enough (it is smaller than
> the money JSR...). This was clearly stated from the start, just remember
> this.
>
This is more vicious since the API of Tamaya hides some implementations
details like the contextuality which is not the default one and not really
"portable" enough to be a standard or the SPI is too complex to be a sane
default and accepted by most users which would better expect the config to
be a plain instance they can make managed in their own system rather than
the opposite
> 3) That you start your initiative outside of Tamaya, indirectly
> damaging/ignoring the work done so far.
>
> So, please collaborate with the guys here on the project, instead of
> running your own thing. Without joining our forces things probably will not
> be successful at all, which would be huge damage. There is much more
> politics involved that you can ever imagine, ignoring that point is simply
> naive IMO.
>
> And the scope discussion basically is something to be taken within a JSR,
> if we have one running...
>
>
Think Mark maybe mixed 2 things in his work:
- the JSR part where you are more than right
- the feature part where he is more than right IMO
To say one more word on that last part I had to implement something close
to DS api 4 times in 1 year and I can't say I was happy with that but it
was the best compromise due to current delivery of DS (topic has been
discussed and outcome was "not better before 2.x") and tamaya behavior was
not matching my expectations. On tamaya side we also tried to make it
smaller and less oppinaited but we failed and can't fight everytime - you
have use cases and we just don't match the way we use config/write apps on
this part.
Hope it gives a bit more sense.
> Thanks, J
> Anatole
>
>
>
>
> 2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
>
>> It really makes a "People's Front of Judea" or maybe rather say "People's
>> Front of JCP" impression here;-)
>>
>> Werner
>>
>>
>> >
>>
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi, I share Anatole's view up to 100%.
Am 15.07.16 um 02:56 schrieb Anatole Tresch:
> Hi all
>
> Folks, calm down a bit. Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being actively
> participating on the project the last months you raise your own initiative
> without involving the other people here.
> 2) That the whole Tamaya project is too bis for a JSR is clear,
> nevertheless the API part may be still small enough (it is smaller than
> the money JSR...). This was clearly stated from the start, just remember
> this.
> 3) That you start your initiative outside of Tamaya, indirectly
> damaging/ignoring the work done so far.
>
> So, please collaborate with the guys here on the project, instead of
> running your own thing. Without joining our forces things probably will not
> be successful at all, which would be huge damage. There is much more
> politics involved that you can ever imagine, ignoring that point is simply
> naive IMO.
>
> And the scope discussion basically is something to be taken within a JSR,
> if we have one running...
>
> Thanks, J
> Anatole
>
>
>
>
> 2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
>
>> It really makes a "People's Front of Judea" or maybe rather say "People's
>> Front of JCP" impression here;-)
>>
>> 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.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Anatole: think we communicated about the design choice we don't like in
tamaya and answer was "you are alone" IIRC but let's try to review some of
them now maybe
2016-07-15 2:56 GMT+02:00 Anatole Tresch <at...@gmail.com>:
> Hi all
>
> Folks, calm down a bit. Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being
> actively participating on the project the last months you raise your own
> initiative without involving the other people here.
> 2) That the whole Tamaya project is too bis for a JSR is clear,
> nevertheless the API part may be still small enough (it is smaller than
> the money JSR...). This was clearly stated from the start, just remember
> this.
>
This is more vicious since the API of Tamaya hides some implementations
details like the contextuality which is not the default one and not really
"portable" enough to be a standard or the SPI is too complex to be a sane
default and accepted by most users which would better expect the config to
be a plain instance they can make managed in their own system rather than
the opposite
> 3) That you start your initiative outside of Tamaya, indirectly
> damaging/ignoring the work done so far.
>
> So, please collaborate with the guys here on the project, instead of
> running your own thing. Without joining our forces things probably will not
> be successful at all, which would be huge damage. There is much more
> politics involved that you can ever imagine, ignoring that point is simply
> naive IMO.
>
> And the scope discussion basically is something to be taken within a JSR,
> if we have one running...
>
>
Think Mark maybe mixed 2 things in his work:
- the JSR part where you are more than right
- the feature part where he is more than right IMO
To say one more word on that last part I had to implement something close
to DS api 4 times in 1 year and I can't say I was happy with that but it
was the best compromise due to current delivery of DS (topic has been
discussed and outcome was "not better before 2.x") and tamaya behavior was
not matching my expectations. On tamaya side we also tried to make it
smaller and less oppinaited but we failed and can't fight everytime - you
have use cases and we just don't match the way we use config/write apps on
this part.
Hope it gives a bit more sense.
> Thanks, J
> Anatole
>
>
>
>
> 2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
>
>> It really makes a "People's Front of Judea" or maybe rather say "People's
>> Front of JCP" impression here;-)
>>
>> Werner
>>
>>
>> >
>>
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> Am 15.07.2016 um 02:56 schrieb Anatole Tresch <at...@gmail.com>:
>
> Hi all
>
> Folks, calm down a bit.
+1, let’s try to turn this into a productive discussion
> Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being actively participating on the project the last months you raise your own initiative without involving the other people here.
You probably remember that Gerhard, Romain and I tried hard to push for a very lightweight solution back then. After we got asked that as a mentor should cut our technical commitment and mostly observe the project. Btw by the same people who boil this up now.
Lets now focus on what >> I << thought was/is the goal of Tamaya and what the current Tamaya community thinks it is.
My initial understanding was that we really push hard to become a JSR in a relatively short time period. Means we should be as powerful as needed BUT as lightweight as possible. The less classes the better. The more straight forward, the better.
Provide
* an API
* a TCK
* a Spec paper
* a RI
And optional some additional modules on top of it.
Was my understanding wrong?
If not, is this still the goal?
If so, look at the current codebase and honestly tell me how close we are to that almost 2 years later?
I checked out the latest sources yesterday and it took me half an hour to at least find the API and RI part.
Btw it also was initially intended to move the config from DeltaSpike to Tamaya. Which neither happened because Tamaya didn’t yet focus on it’s core business.
Btw 2, the stuff I published on github was actually not based on Tamaya but on the stuff I wrote in DeltaSpike.
> 2) That the whole Tamaya project is too bis for a JSR is clear, nevertheless the API part may be still small enough (it is smaller than the money JSR...). This was clearly stated from the start, just remember this.
Yes, I remember this well and I wonder where we derailed (at least from my pov).
Don’t get me wrong I STILL think it is possible to review the API and cut it down to the bare minimun to get the project back on track for a JSR.
Again this is only MY personal view. Maybe all others think the project is doing perfectly fine anyway and the API is already the best you can think of.
After all, it boils down to whether we are talking about the same goals…
Remember where we started. We had about 10 different configuration projects to look at. We added 300 classes and then reviewed the core ideas and concepts behind it.
It seems that the algorithm Gerhard and I created for OWB, CODI and finally DeltaSpike made the race and we got rid of most stuff which were previously added.
I guess you nowadays see the power of this approach and we share a common idea, right?
There are imo 3 different sizes which are possible
Option 1.) the really bare core
* ConfigProvider + Config
* ConfigSource chain (including ConfigSourceProvider) + ConfigFilter chain
Essentially we don’t even need ConfigFileProvider. It could easily be done as addon.
That makes exactly 5 interface classes for that whole thing!
Intentionally left out:
* It only handles String/String, no other Types! Why? Because it can easily added on top of it anyway…
* No List, Set, etc handling! This adds huge complexity for a very limited benefit.
* No lookup chain like variable evaluation, ’staged’ lookup like DeltaSpike ProjectStage. Why? Because it can easily added on top of it anyway…
* No fancy other ConfigSources out of the box. Why? See above…
* No DI support, again can easily get added on top.
Option 2.) like 1.) but with a Coverter logic for other types than Strings, caching, variable expression, lookup chain.
Makes another 2 classes: Converter and TypedResolver (written by Gerhard a long time ago)
See
https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java#L636
http://deltaspike.apache.org/documentation/configuration.html#_typedresolver_api
Option 3.)
The fully blown Tamaya logic. Not sure what the other 20 interfaces aim for. But it’s somehow clear that there are parts we might potentially get rid of.
E.g. ConfigQuery, ConfigOperator? Tried to understand that a long time ago and always failed. Maybe it’s a tad too flexible?
> There is much more politics involved that you can ever imagine, ignoring that point is simply naive IMO.
You know, I’m a bloody technician and not that much interested in politics. But you are most probably right with this point ;)
LieGrue,
strub
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Well the damage (Mark caused by this) is done, neither now nor next week it
can be fully undone;-O
However by following up on a constructive discussion whenever everyone is
are ready after the weekend the cause of a configuration standard could
probably be best served.
If there's a Hangout etc. at a decent time happy to also join that.
Cheers,
Werner
On Fri, Jul 15, 2016 at 8:00 PM, John D. Ament <jo...@apache.org>
wrote:
> Werner,
>
> Let's keep Alan's proposed moratorium.
>
> John
>
> On Jul 15, 2016 13:56, "Werner Keil" <we...@gmail.com> wrote:
>
> > Former DeviceMap comitter and PMC chair Reza was also the original author
> > of many parts of what he moved to GitHub in a fork, but folks like
> Bertrand
> > who's also on the Apache board were pretty clear, he must not continue to
> > develop that under the "Apache" brand or "org.apache.*" as you did in
> your
> > private fork of "something".
> >
> > I am not even bothering to discuss the "javax.*" mistake further, it's
> just
> > wrong at the wrong time in the wrong place.
> >
> > The only good thing is a discussion in the Tamaya list about design
> > aspects.
> >
> > This could have happened in a much more sensitive and more appropriate
> way.
> >
> > People everywhere not just at Oracle look with great scrutiny at Open
> > Source and as we see from the Java EE 8 discussion and all the resources
> at
> > Oracle and elsewhere drawn from Open Source into commercial, Closes
> Source
> > proprietary solutions instead of open standards.
> >
> > However, even if Oracle was to stop working on Java EE you must not
> simply
> > go and say "Oh, those lazy bones, I'm going to create my own Java
> standard
> > instead".
> > Or what next, "Sorry W3C, you take way too long with HTML5, I now create
> > HTML6 in my own GitHub repository and everyone will use it"?;-D
> >
> > You may have done this with the bet intentions, but did great damage to
> the
> > impression people have of Open Source, Open Java, the JCP and also
> Apache.
> > It helped only those who claim "those Open Source guys are a bunch of
> > anarchists who can't make up their minds and don't produce anything of
> > value".
> >
> > Not sure, if you really intended to do that, but that's how it went, so
> > please try to be a little more thoughtful and ask people who are involved
> > in the process (PMO or EC if you plan to file a JSR;-) next time.
> >
> > Cheers,
> > Werner
> >
> >
> > On Fri, Jul 15, 2016 at 10:44 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> > >
> > > > Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
> > > >
> > > > Tamaya will know best, if it tolerates a fork of
> > > > Geronimo in the way Mark created it.
> > >
> > >
> > > Wow! Dude, you got something horribly wrong.
> > >
> > > That stuff is in no way a fork of Tamaya. It’s just the core bits I
> wrote
> > > in DeltaSpike configuration.
> > > In DeltaSpike this exists since 2011.
> > >
> > >
> >
> https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
> > >
> > > And the very core (various config sources ordered by a config_ordinal)
> > > even dates back to my work in OpenWebBeans as of 2010
> > >
> > >
> >
> https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
> > > Gerhard Petracek then also helped a great deal later in CODI and in
> > > DeltaSpike. But that’s pretty much it.
> > >
> > > So who forked whom? …
> > > To get this straight: I am the original author of this algorithm and
> API
> > > design.
> > >
> > > LieGrue,
> > > strub
> >
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Well the damage (Mark caused by this) is done, neither now nor next week it
can be fully undone;-O
However by following up on a constructive discussion whenever everyone is
are ready after the weekend the cause of a configuration standard could
probably be best served.
If there's a Hangout etc. at a decent time happy to also join that.
Cheers,
Werner
On Fri, Jul 15, 2016 at 8:00 PM, John D. Ament <jo...@apache.org>
wrote:
> Werner,
>
> Let's keep Alan's proposed moratorium.
>
> John
>
> On Jul 15, 2016 13:56, "Werner Keil" <we...@gmail.com> wrote:
>
> > Former DeviceMap comitter and PMC chair Reza was also the original author
> > of many parts of what he moved to GitHub in a fork, but folks like
> Bertrand
> > who's also on the Apache board were pretty clear, he must not continue to
> > develop that under the "Apache" brand or "org.apache.*" as you did in
> your
> > private fork of "something".
> >
> > I am not even bothering to discuss the "javax.*" mistake further, it's
> just
> > wrong at the wrong time in the wrong place.
> >
> > The only good thing is a discussion in the Tamaya list about design
> > aspects.
> >
> > This could have happened in a much more sensitive and more appropriate
> way.
> >
> > People everywhere not just at Oracle look with great scrutiny at Open
> > Source and as we see from the Java EE 8 discussion and all the resources
> at
> > Oracle and elsewhere drawn from Open Source into commercial, Closes
> Source
> > proprietary solutions instead of open standards.
> >
> > However, even if Oracle was to stop working on Java EE you must not
> simply
> > go and say "Oh, those lazy bones, I'm going to create my own Java
> standard
> > instead".
> > Or what next, "Sorry W3C, you take way too long with HTML5, I now create
> > HTML6 in my own GitHub repository and everyone will use it"?;-D
> >
> > You may have done this with the bet intentions, but did great damage to
> the
> > impression people have of Open Source, Open Java, the JCP and also
> Apache.
> > It helped only those who claim "those Open Source guys are a bunch of
> > anarchists who can't make up their minds and don't produce anything of
> > value".
> >
> > Not sure, if you really intended to do that, but that's how it went, so
> > please try to be a little more thoughtful and ask people who are involved
> > in the process (PMO or EC if you plan to file a JSR;-) next time.
> >
> > Cheers,
> > Werner
> >
> >
> > On Fri, Jul 15, 2016 at 10:44 AM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> > >
> > > > Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
> > > >
> > > > Tamaya will know best, if it tolerates a fork of
> > > > Geronimo in the way Mark created it.
> > >
> > >
> > > Wow! Dude, you got something horribly wrong.
> > >
> > > That stuff is in no way a fork of Tamaya. It’s just the core bits I
> wrote
> > > in DeltaSpike configuration.
> > > In DeltaSpike this exists since 2011.
> > >
> > >
> >
> https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
> > >
> > > And the very core (various config sources ordered by a config_ordinal)
> > > even dates back to my work in OpenWebBeans as of 2010
> > >
> > >
> >
> https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
> > > Gerhard Petracek then also helped a great deal later in CODI and in
> > > DeltaSpike. But that’s pretty much it.
> > >
> > > So who forked whom? …
> > > To get this straight: I am the original author of this algorithm and
> API
> > > design.
> > >
> > > LieGrue,
> > > strub
> >
>
Re: Configuration for Java SE and Java EE JSR
Posted by "John D. Ament" <jo...@apache.org>.
Werner,
Let's keep Alan's proposed moratorium.
John
On Jul 15, 2016 13:56, "Werner Keil" <we...@gmail.com> wrote:
> Former DeviceMap comitter and PMC chair Reza was also the original author
> of many parts of what he moved to GitHub in a fork, but folks like Bertrand
> who's also on the Apache board were pretty clear, he must not continue to
> develop that under the "Apache" brand or "org.apache.*" as you did in your
> private fork of "something".
>
> I am not even bothering to discuss the "javax.*" mistake further, it's just
> wrong at the wrong time in the wrong place.
>
> The only good thing is a discussion in the Tamaya list about design
> aspects.
>
> This could have happened in a much more sensitive and more appropriate way.
>
> People everywhere not just at Oracle look with great scrutiny at Open
> Source and as we see from the Java EE 8 discussion and all the resources at
> Oracle and elsewhere drawn from Open Source into commercial, Closes Source
> proprietary solutions instead of open standards.
>
> However, even if Oracle was to stop working on Java EE you must not simply
> go and say "Oh, those lazy bones, I'm going to create my own Java standard
> instead".
> Or what next, "Sorry W3C, you take way too long with HTML5, I now create
> HTML6 in my own GitHub repository and everyone will use it"?;-D
>
> You may have done this with the bet intentions, but did great damage to the
> impression people have of Open Source, Open Java, the JCP and also Apache.
> It helped only those who claim "those Open Source guys are a bunch of
> anarchists who can't make up their minds and don't produce anything of
> value".
>
> Not sure, if you really intended to do that, but that's how it went, so
> please try to be a little more thoughtful and ask people who are involved
> in the process (PMO or EC if you plan to file a JSR;-) next time.
>
> Cheers,
> Werner
>
>
> On Fri, Jul 15, 2016 at 10:44 AM, Mark Struberg <st...@yahoo.de> wrote:
>
> >
> > > Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
> > >
> > > Tamaya will know best, if it tolerates a fork of
> > > Geronimo in the way Mark created it.
> >
> >
> > Wow! Dude, you got something horribly wrong.
> >
> > That stuff is in no way a fork of Tamaya. It’s just the core bits I wrote
> > in DeltaSpike configuration.
> > In DeltaSpike this exists since 2011.
> >
> >
> https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
> >
> > And the very core (various config sources ordered by a config_ordinal)
> > even dates back to my work in OpenWebBeans as of 2010
> >
> >
> https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
> > Gerhard Petracek then also helped a great deal later in CODI and in
> > DeltaSpike. But that’s pretty much it.
> >
> > So who forked whom? …
> > To get this straight: I am the original author of this algorithm and API
> > design.
> >
> > LieGrue,
> > strub
>
Re: Configuration for Java SE and Java EE JSR
Posted by "John D. Ament" <jo...@apache.org>.
Werner,
Let's keep Alan's proposed moratorium.
John
On Jul 15, 2016 13:56, "Werner Keil" <we...@gmail.com> wrote:
> Former DeviceMap comitter and PMC chair Reza was also the original author
> of many parts of what he moved to GitHub in a fork, but folks like Bertrand
> who's also on the Apache board were pretty clear, he must not continue to
> develop that under the "Apache" brand or "org.apache.*" as you did in your
> private fork of "something".
>
> I am not even bothering to discuss the "javax.*" mistake further, it's just
> wrong at the wrong time in the wrong place.
>
> The only good thing is a discussion in the Tamaya list about design
> aspects.
>
> This could have happened in a much more sensitive and more appropriate way.
>
> People everywhere not just at Oracle look with great scrutiny at Open
> Source and as we see from the Java EE 8 discussion and all the resources at
> Oracle and elsewhere drawn from Open Source into commercial, Closes Source
> proprietary solutions instead of open standards.
>
> However, even if Oracle was to stop working on Java EE you must not simply
> go and say "Oh, those lazy bones, I'm going to create my own Java standard
> instead".
> Or what next, "Sorry W3C, you take way too long with HTML5, I now create
> HTML6 in my own GitHub repository and everyone will use it"?;-D
>
> You may have done this with the bet intentions, but did great damage to the
> impression people have of Open Source, Open Java, the JCP and also Apache.
> It helped only those who claim "those Open Source guys are a bunch of
> anarchists who can't make up their minds and don't produce anything of
> value".
>
> Not sure, if you really intended to do that, but that's how it went, so
> please try to be a little more thoughtful and ask people who are involved
> in the process (PMO or EC if you plan to file a JSR;-) next time.
>
> Cheers,
> Werner
>
>
> On Fri, Jul 15, 2016 at 10:44 AM, Mark Struberg <st...@yahoo.de> wrote:
>
> >
> > > Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
> > >
> > > Tamaya will know best, if it tolerates a fork of
> > > Geronimo in the way Mark created it.
> >
> >
> > Wow! Dude, you got something horribly wrong.
> >
> > That stuff is in no way a fork of Tamaya. It’s just the core bits I wrote
> > in DeltaSpike configuration.
> > In DeltaSpike this exists since 2011.
> >
> >
> https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
> >
> > And the very core (various config sources ordered by a config_ordinal)
> > even dates back to my work in OpenWebBeans as of 2010
> >
> >
> https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
> > Gerhard Petracek then also helped a great deal later in CODI and in
> > DeltaSpike. But that’s pretty much it.
> >
> > So who forked whom? …
> > To get this straight: I am the original author of this algorithm and API
> > design.
> >
> > LieGrue,
> > strub
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Former DeviceMap comitter and PMC chair Reza was also the original author
of many parts of what he moved to GitHub in a fork, but folks like Bertrand
who's also on the Apache board were pretty clear, he must not continue to
develop that under the "Apache" brand or "org.apache.*" as you did in your
private fork of "something".
I am not even bothering to discuss the "javax.*" mistake further, it's just
wrong at the wrong time in the wrong place.
The only good thing is a discussion in the Tamaya list about design
aspects.
This could have happened in a much more sensitive and more appropriate way.
People everywhere not just at Oracle look with great scrutiny at Open
Source and as we see from the Java EE 8 discussion and all the resources at
Oracle and elsewhere drawn from Open Source into commercial, Closes Source
proprietary solutions instead of open standards.
However, even if Oracle was to stop working on Java EE you must not simply
go and say "Oh, those lazy bones, I'm going to create my own Java standard
instead".
Or what next, "Sorry W3C, you take way too long with HTML5, I now create
HTML6 in my own GitHub repository and everyone will use it"?;-D
You may have done this with the bet intentions, but did great damage to the
impression people have of Open Source, Open Java, the JCP and also Apache.
It helped only those who claim "those Open Source guys are a bunch of
anarchists who can't make up their minds and don't produce anything of
value".
Not sure, if you really intended to do that, but that's how it went, so
please try to be a little more thoughtful and ask people who are involved
in the process (PMO or EC if you plan to file a JSR;-) next time.
Cheers,
Werner
On Fri, Jul 15, 2016 at 10:44 AM, Mark Struberg <st...@yahoo.de> wrote:
>
> > Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
> >
> > Tamaya will know best, if it tolerates a fork of
> > Geronimo in the way Mark created it.
>
>
> Wow! Dude, you got something horribly wrong.
>
> That stuff is in no way a fork of Tamaya. It’s just the core bits I wrote
> in DeltaSpike configuration.
> In DeltaSpike this exists since 2011.
>
> https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
>
> And the very core (various config sources ordered by a config_ordinal)
> even dates back to my work in OpenWebBeans as of 2010
>
> https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
> Gerhard Petracek then also helped a great deal later in CODI and in
> DeltaSpike. But that’s pretty much it.
>
> So who forked whom? …
> To get this straight: I am the original author of this algorithm and API
> design.
>
> LieGrue,
> strub
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Former DeviceMap comitter and PMC chair Reza was also the original author
of many parts of what he moved to GitHub in a fork, but folks like Bertrand
who's also on the Apache board were pretty clear, he must not continue to
develop that under the "Apache" brand or "org.apache.*" as you did in your
private fork of "something".
I am not even bothering to discuss the "javax.*" mistake further, it's just
wrong at the wrong time in the wrong place.
The only good thing is a discussion in the Tamaya list about design
aspects.
This could have happened in a much more sensitive and more appropriate way.
People everywhere not just at Oracle look with great scrutiny at Open
Source and as we see from the Java EE 8 discussion and all the resources at
Oracle and elsewhere drawn from Open Source into commercial, Closes Source
proprietary solutions instead of open standards.
However, even if Oracle was to stop working on Java EE you must not simply
go and say "Oh, those lazy bones, I'm going to create my own Java standard
instead".
Or what next, "Sorry W3C, you take way too long with HTML5, I now create
HTML6 in my own GitHub repository and everyone will use it"?;-D
You may have done this with the bet intentions, but did great damage to the
impression people have of Open Source, Open Java, the JCP and also Apache.
It helped only those who claim "those Open Source guys are a bunch of
anarchists who can't make up their minds and don't produce anything of
value".
Not sure, if you really intended to do that, but that's how it went, so
please try to be a little more thoughtful and ask people who are involved
in the process (PMO or EC if you plan to file a JSR;-) next time.
Cheers,
Werner
On Fri, Jul 15, 2016 at 10:44 AM, Mark Struberg <st...@yahoo.de> wrote:
>
> > Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
> >
> > Tamaya will know best, if it tolerates a fork of
> > Geronimo in the way Mark created it.
>
>
> Wow! Dude, you got something horribly wrong.
>
> That stuff is in no way a fork of Tamaya. It’s just the core bits I wrote
> in DeltaSpike configuration.
> In DeltaSpike this exists since 2011.
>
> https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
>
> And the very core (various config sources ordered by a config_ordinal)
> even dates back to my work in OpenWebBeans as of 2010
>
> https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
> Gerhard Petracek then also helped a great deal later in CODI and in
> DeltaSpike. But that’s pretty much it.
>
> So who forked whom? …
> To get this straight: I am the original author of this algorithm and API
> design.
>
> LieGrue,
> strub
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de>.
> Am 15.07.2016 um 09:31 schrieb Werner Keil <we...@gmail.com>:
>
> Tamaya will know best, if it tolerates a fork of
> Geronimo in the way Mark created it.
Wow! Dude, you got something horribly wrong.
That stuff is in no way a fork of Tamaya. It’s just the core bits I wrote in DeltaSpike configuration.
In DeltaSpike this exists since 2011.
https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736
And the very core (various config sources ordered by a config_ordinal) even dates back to my work in OpenWebBeans as of 2010
https://github.com/apache/openwebbeans/commit/eccc84cbba8d2e823f4aa0ab626e1d7560f78486
Gerhard Petracek then also helped a great deal later in CODI and in DeltaSpike. But that’s pretty much it.
So who forked whom? …
To get this straight: I am the original author of this algorithm and API design.
LieGrue,
strub
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Anatole/all,
Thanks for the feedback. I know how the likes of those at Oracle would (or
will) respond to this who also are half-way entangled between legal and
development. E.g. Jim Wright, who told JSRs like the one I lead with others
to use Apache 2.0 then only to declare the Apache license was incompatible
with OpenJDK and the JCP ;-|
Also John who has been helpful and very clear about Apache's legal views
and requirements towards Tamaya will know best, if it tolerates a fork of
Geronimo in the way Mark created it. I know, when former committers to
DeviceMap created a similar fork on GitHub they were told they may do so,
but not call it"org.apache" either.
I hope you guys can settle differences and work constructively together,
both at Apache, JCP or elsewhere.
Cheers,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Fri, Jul 15, 2016 at 2:56 AM, Anatole Tresch <at...@gmail.com> wrote:
> Hi all
>
> Folks, calm down a bit. Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being actively
> participating on the project the last months you raise your own initiative
> without involving the other people here.
> 2) That the whole Tamaya project is too bis for a JSR is clear,
> nevertheless the API part may be still small enough (it is smaller than
> the money JSR...). This was clearly stated from the start, just remember
> this.
> 3) That you start your initiative outside of Tamaya, indirectly
> damaging/ignoring the work done so far.
>
> So, please collaborate with the guys here on the project, instead of
> running your own thing. Without joining our forces things probably will not
> be successful at all, which would be huge damage. There is much more
> politics involved that you can ever imagine, ignoring that point is simply
> naive IMO.
>
> And the scope discussion basically is something to be taken within a JSR,
> if we have one running...
>
> Thanks, J
> Anatole
>
>
>
>
> 2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
>
> > It really makes a "People's Front of Judea" or maybe rather say "People's
> > Front of JCP" impression here;-)
> >
> > Werner
> >
> >
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Anatole/all,
Thanks for the feedback. I know how the likes of those at Oracle would (or
will) respond to this who also are half-way entangled between legal and
development. E.g. Jim Wright, who told JSRs like the one I lead with others
to use Apache 2.0 then only to declare the Apache license was incompatible
with OpenJDK and the JCP ;-|
Also John who has been helpful and very clear about Apache's legal views
and requirements towards Tamaya will know best, if it tolerates a fork of
Geronimo in the way Mark created it. I know, when former committers to
DeviceMap created a similar fork on GitHub they were told they may do so,
but not call it"org.apache" either.
I hope you guys can settle differences and work constructively together,
both at Apache, JCP or elsewhere.
Cheers,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Fri, Jul 15, 2016 at 2:56 AM, Anatole Tresch <at...@gmail.com> wrote:
> Hi all
>
> Folks, calm down a bit. Neverthess what I really dislike, is
>
> 1) that after so much work done, and neither Mark nor Romain being actively
> participating on the project the last months you raise your own initiative
> without involving the other people here.
> 2) That the whole Tamaya project is too bis for a JSR is clear,
> nevertheless the API part may be still small enough (it is smaller than
> the money JSR...). This was clearly stated from the start, just remember
> this.
> 3) That you start your initiative outside of Tamaya, indirectly
> damaging/ignoring the work done so far.
>
> So, please collaborate with the guys here on the project, instead of
> running your own thing. Without joining our forces things probably will not
> be successful at all, which would be huge damage. There is much more
> politics involved that you can ever imagine, ignoring that point is simply
> naive IMO.
>
> And the scope discussion basically is something to be taken within a JSR,
> if we have one running...
>
> Thanks, J
> Anatole
>
>
>
>
> 2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
>
> > It really makes a "People's Front of Judea" or maybe rather say "People's
> > Front of JCP" impression here;-)
> >
> > Werner
> >
> >
> > >
> >
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Hi all
Folks, calm down a bit. Neverthess what I really dislike, is
1) that after so much work done, and neither Mark nor Romain being actively
participating on the project the last months you raise your own initiative
without involving the other people here.
2) That the whole Tamaya project is too bis for a JSR is clear,
nevertheless the API part may be still small enough (it is smaller than
the money JSR...). This was clearly stated from the start, just remember
this.
3) That you start your initiative outside of Tamaya, indirectly
damaging/ignoring the work done so far.
So, please collaborate with the guys here on the project, instead of
running your own thing. Without joining our forces things probably will not
be successful at all, which would be huge damage. There is much more
politics involved that you can ever imagine, ignoring that point is simply
naive IMO.
And the scope discussion basically is something to be taken within a JSR,
if we have one running...
Thanks, J
Anatole
2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
> It really makes a "People's Front of Judea" or maybe rather say "People's
> Front of JCP" impression here;-)
>
> Werner
>
>
> >
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Anatole Tresch <at...@gmail.com>.
Hi all
Folks, calm down a bit. Neverthess what I really dislike, is
1) that after so much work done, and neither Mark nor Romain being actively
participating on the project the last months you raise your own initiative
without involving the other people here.
2) That the whole Tamaya project is too bis for a JSR is clear,
nevertheless the API part may be still small enough (it is smaller than
the money JSR...). This was clearly stated from the start, just remember
this.
3) That you start your initiative outside of Tamaya, indirectly
damaging/ignoring the work done so far.
So, please collaborate with the guys here on the project, instead of
running your own thing. Without joining our forces things probably will not
be successful at all, which would be huge damage. There is much more
politics involved that you can ever imagine, ignoring that point is simply
naive IMO.
And the scope discussion basically is something to be taken within a JSR,
if we have one running...
Thanks, J
Anatole
2016-07-15 2:07 GMT+02:00 Werner Keil <we...@gmail.com>:
> It really makes a "People's Front of Judea" or maybe rather say "People's
> Front of JCP" impression here;-)
>
> Werner
>
>
> >
>
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Besides from a technical point "Doing this at Geronimo", who would do this
in 2016?
http://geronimo.apache.org/ shows no release or activity for the past 3
years. While TomEE (though it so far aims at the Web profile only, also not
yet Java EE 7 certified) makes a very active and healthy impression. David
isn't only active in several Java EE JSRs Tomitribe together with others
(several major container providers) launched the "Microprofile" idea and
also got Oracle's attention.
Better speak to some of those guys, maybe when the time is right also to
try form an EG, but not try to push your own rogue standard in a
cloak-and-dagger-operation.
Otavio who's also in the Tamaya poddling did this slightly more sensitive.
Though the JNOSQL structure contains module skeletons those seem more like
the idea and preparation towards an Apache Incubator proposal than putting
something like "javax.nosql" there now and all by himself;-)
Although he has not even proposed the Apache project others in the EC
sounded open to the idea, but they probably won't suddently throw out their
idea of "javax.nosql" either;-)
JCache took a very long time and was largely influenced by projects like
EHCache.
If you just take the very top level org.apache.tamaya and maybe
org.apache.tamaya.spi, those packages and very small independent modules
feel like something to look into.
Maybe with other projects or proposals, but until a JSR is formally
approved none of that deserves to call itself "javax.config" or whatever;-)
Cheers,
Werner
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
It really makes a "People's Front of Judea" or maybe rather say "People's
Front of JCP" impression here;-)
Werner
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
It really makes a "People's Front of Judea" or maybe rather say "People's
Front of JCP" impression here;-)
Werner
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Even if you may have studied law you don't seem to practice it either, but
I spent enough years in the EC to understand and help progress the
structures of the JCP.
If Oracle projects like XML so and so were used for the JDK so be it, but
one cannot simply say "I don't like what's in java.lang, I create my own
Java". Wait, Harmony tried that, but they stopped;-D
JSR 310 Spec Lead and JSR 354 EG Member Stephen Colebourne tried to
establish "Apache Commons Money" a while ago. I don't think you still find
it, because it must be archived now. He was unhappy with the "too
democratic" and "too slow" process at Apache (as he told me some while ago)
so he took his ideas creating JodaMoney. Which still exists. A bit of it
ended up as an inspiration for JSR 354 but at no point he either kept
calling it "org.apache.commons.money" nor "javax.money" till JSR 354 was
proposed and approved with Victor Grazi as Spec Lead. He then helped Victor
and later Anatole as Spec Leads. Some ideas and designs remained, others
(also based on feedback by the EC or wider community) were changed.
However, everyone respected the boundaries of when the JSR started to
exist, that's not the case here.
File the proposal on JCP.org if you think it's ready, otherwise this is
just a rogue piece of code and further disruption of the Java (EE)
ecosystem than what's already going on, but all others respect those
boundaries, e.g. trying to define their own stuff under "org.joda", "
microservice.io" (some of which may or may not flow back into JSRs) or
elsewhere.
So better stick to a neutral package space. Otherwise nobody especially not
the EC are likely to take it seriously if somebody tries to create a fait
accompli just because the other 6 or 7 alternatives out there don't suit
them ;-)
Even after Bean Binding JSR (295) was stopped or withdrawn the makers of
"Better Bean Binding" stuck to
it.tidalwave.betterbeansbinding
Cheers,
Werner
On Fri, Jul 15, 2016 at 1:06 AM, Mark Struberg <st...@yahoo.de.invalid>
wrote:
> You know that this is a chicken-egg problem and that there are many
> projects which did totally different?
> Oracle is also actively using the org.apache package names, whoops …
> Lets stop that legal discussion. You are not a lawyer.
>
> LieGrue,
> strub
>
>
> > Am 15.07.2016 um 00:57 schrieb Werner Keil <we...@gmail.com>:
> >
> > What's out on GitHub is taken for granted and can be forked and cloned as
> > you know.
> >
> > A POC must not be called javax.config without a JSR ever being proposed
> or
> > accepted just to try out "how it feels".
> > When JSR 275 was stopped we took the ideas and working concepts to a new
> > project "unitsofmeasurement.org" for almost 5 years, not just do a
> "rogue
> > JSR".
> > Only when JSR 363 was approved we reused the namespace.
> >
> > So as a POC call it "config" if you like but not "javax.config",
> > "java.config" or "jdk.config" that implies a working JSR or parts of the
> > JDK;-)
> >
> > Cheers
> >
> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >
> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
> > | #DevOps | #EclipseUOMo
> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >
> >
> >
> > On Fri, Jul 15, 2016 at 12:48 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
> >>>
> >>> Yes but neither at Apache nor elsewhere you can just go and declare
> "your
> >>> JSR", this is unacceptable especially from the package space point.
> >>> A JSR under "javax.something" is only allowed for an EG once a JSR was
> >>> filed and approved by the Executive Committee.
> >>>
> >>> Mark is free to register any domain like "marksconfig.io" because .io
> is
> >>> just hip now and used by everybody and declare that project on GitHub.
> >>> If someone wishes to propose a new JSR, go ahead and do so under
> >>> https://www.jcp.org/en/jsr/proposal but not like that ;-(
> >>>
> >>> Nobody did so, thus if it ever happened, any of the mentioned projects
> >> may
> >>> be listed as "initial contribution", inspiration or whatever, but
> simply
> >>> throwing something out there under javax.config is unconstructive, just
> >>> because you you're unhappy with either Apache Commons Config, Typesafe
> >>> Config, Spring Config, DeltaSpike Config or Tamaya.
> >>>
> >>
> >> It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
> >> yet on details
> >>
> >>> Cheers,
> >>> Werner
> >>>
> >>>
> >>> On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >>> wrote:
> >>>
> >>>> Tamaya is far beyond a JSR in design and impl. It is a promishing
> >> product
> >>>> but too opponiated to be a JSR today IMO. Config needs something
> >> smaller.
> >>>> DS solution is a pretty good start for that.
> >>>>
> >>>> Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o.b.fischer@swe-blog.net
> >
> >> a
> >>>> écrit :
> >>>>
> >>>>> I a little bit confused. As I know our common goal is to establish a
> >>>>> configuration JSR based on Tamaya. I wouldn't like to see here a race
> >> for
> >>>>> the one how submits its JSR first....
> >>>>>
> >>>>>
> >>>>> Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> >>>>>
> >>>>>> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> >>>> Tamaya
> >>>>>> for asf.
> >>>>>>
> >>>>>>
> >>>>>> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> >>>> écrit :
> >>>>>>
> >>>>>> Doesn't this overlap with another project you've been involved with,
> >>>>>>> Tamaya?
> >>>>>>>
> >>>>>>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de>
> >> wrote:
> >>>>>>>
> >>>>>>> Hi folks!
> >>>>>>>
> >>>>>>> I’ve started to extract the configuration work I’ve done in OWB,
> >>>> MyFaces
> >>>>>>> and DeltaSpike into an own little project.
> >>>>>>> For the MyFaces and DeltaSpike parts I got help from ASF member
> >> Gerhard
> >>>>>>> Petracek.
> >>>>>>>
> >>>>>>> My goal is to establish an own JSR for configuration.
> >>>>>>>
> >>>>>>> So far it consists of 2 classes for the API and 4 classes for the
> >> SPI.
> >>>>>>> The source can be found here.
> >>>>>>> https://github.com/struberg/javaConfig
> >>>>>>>
> >>>>>>> And that’s pretty much it! There is not much more needed for it.
> >>>>>>>
> >>>>>>> I would love to move this to Geronimo. Simply because geronimo is
> >> kind
> >>>> of
> >>>>>>> an EE-commons for the ASF nowadays ;)
> >>>>>>>
> >>>>>>> wdyt?
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> N Oliver B. Fischer
> >>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>>> P +49 30 44793251
> >>>>> M +49 178 7903538
> >>>>> E o.b.fischer@swe-blog.net
> >>>>> S oliver.b.fischer
> >>>>> J oliver.b.fischer@jabber.org
> >>>>> X http://xing.to/obf
> >>>>>
> >>>>>
> >>>>
> >>
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Even if you may have studied law you don't seem to practice it either, but
I spent enough years in the EC to understand and help progress the
structures of the JCP.
If Oracle projects like XML so and so were used for the JDK so be it, but
one cannot simply say "I don't like what's in java.lang, I create my own
Java". Wait, Harmony tried that, but they stopped;-D
JSR 310 Spec Lead and JSR 354 EG Member Stephen Colebourne tried to
establish "Apache Commons Money" a while ago. I don't think you still find
it, because it must be archived now. He was unhappy with the "too
democratic" and "too slow" process at Apache (as he told me some while ago)
so he took his ideas creating JodaMoney. Which still exists. A bit of it
ended up as an inspiration for JSR 354 but at no point he either kept
calling it "org.apache.commons.money" nor "javax.money" till JSR 354 was
proposed and approved with Victor Grazi as Spec Lead. He then helped Victor
and later Anatole as Spec Leads. Some ideas and designs remained, others
(also based on feedback by the EC or wider community) were changed.
However, everyone respected the boundaries of when the JSR started to
exist, that's not the case here.
File the proposal on JCP.org if you think it's ready, otherwise this is
just a rogue piece of code and further disruption of the Java (EE)
ecosystem than what's already going on, but all others respect those
boundaries, e.g. trying to define their own stuff under "org.joda", "
microservice.io" (some of which may or may not flow back into JSRs) or
elsewhere.
So better stick to a neutral package space. Otherwise nobody especially not
the EC are likely to take it seriously if somebody tries to create a fait
accompli just because the other 6 or 7 alternatives out there don't suit
them ;-)
Even after Bean Binding JSR (295) was stopped or withdrawn the makers of
"Better Bean Binding" stuck to
it.tidalwave.betterbeansbinding
Cheers,
Werner
On Fri, Jul 15, 2016 at 1:06 AM, Mark Struberg <st...@yahoo.de.invalid>
wrote:
> You know that this is a chicken-egg problem and that there are many
> projects which did totally different?
> Oracle is also actively using the org.apache package names, whoops …
> Lets stop that legal discussion. You are not a lawyer.
>
> LieGrue,
> strub
>
>
> > Am 15.07.2016 um 00:57 schrieb Werner Keil <we...@gmail.com>:
> >
> > What's out on GitHub is taken for granted and can be forked and cloned as
> > you know.
> >
> > A POC must not be called javax.config without a JSR ever being proposed
> or
> > accepted just to try out "how it feels".
> > When JSR 275 was stopped we took the ideas and working concepts to a new
> > project "unitsofmeasurement.org" for almost 5 years, not just do a
> "rogue
> > JSR".
> > Only when JSR 363 was approved we reused the namespace.
> >
> > So as a POC call it "config" if you like but not "javax.config",
> > "java.config" or "jdk.config" that implies a working JSR or parts of the
> > JDK;-)
> >
> > Cheers
> >
> > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> > Eclipse UOMo Lead, Babel Language Champion | Apache Committer
> >
> > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
> > | #DevOps | #EclipseUOMo
> > Skype werner.keil | Google+ gplus.to/wernerkeil
> >
> >
> >
> > On Fri, Jul 15, 2016 at 12:48 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
> >>>
> >>> Yes but neither at Apache nor elsewhere you can just go and declare
> "your
> >>> JSR", this is unacceptable especially from the package space point.
> >>> A JSR under "javax.something" is only allowed for an EG once a JSR was
> >>> filed and approved by the Executive Committee.
> >>>
> >>> Mark is free to register any domain like "marksconfig.io" because .io
> is
> >>> just hip now and used by everybody and declare that project on GitHub.
> >>> If someone wishes to propose a new JSR, go ahead and do so under
> >>> https://www.jcp.org/en/jsr/proposal but not like that ;-(
> >>>
> >>> Nobody did so, thus if it ever happened, any of the mentioned projects
> >> may
> >>> be listed as "initial contribution", inspiration or whatever, but
> simply
> >>> throwing something out there under javax.config is unconstructive, just
> >>> because you you're unhappy with either Apache Commons Config, Typesafe
> >>> Config, Spring Config, DeltaSpike Config or Tamaya.
> >>>
> >>
> >> It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
> >> yet on details
> >>
> >>> Cheers,
> >>> Werner
> >>>
> >>>
> >>> On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >>> wrote:
> >>>
> >>>> Tamaya is far beyond a JSR in design and impl. It is a promishing
> >> product
> >>>> but too opponiated to be a JSR today IMO. Config needs something
> >> smaller.
> >>>> DS solution is a pretty good start for that.
> >>>>
> >>>> Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o.b.fischer@swe-blog.net
> >
> >> a
> >>>> écrit :
> >>>>
> >>>>> I a little bit confused. As I know our common goal is to establish a
> >>>>> configuration JSR based on Tamaya. I wouldn't like to see here a race
> >> for
> >>>>> the one how submits its JSR first....
> >>>>>
> >>>>>
> >>>>> Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> >>>>>
> >>>>>> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> >>>> Tamaya
> >>>>>> for asf.
> >>>>>>
> >>>>>>
> >>>>>> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> >>>> écrit :
> >>>>>>
> >>>>>> Doesn't this overlap with another project you've been involved with,
> >>>>>>> Tamaya?
> >>>>>>>
> >>>>>>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de>
> >> wrote:
> >>>>>>>
> >>>>>>> Hi folks!
> >>>>>>>
> >>>>>>> I’ve started to extract the configuration work I’ve done in OWB,
> >>>> MyFaces
> >>>>>>> and DeltaSpike into an own little project.
> >>>>>>> For the MyFaces and DeltaSpike parts I got help from ASF member
> >> Gerhard
> >>>>>>> Petracek.
> >>>>>>>
> >>>>>>> My goal is to establish an own JSR for configuration.
> >>>>>>>
> >>>>>>> So far it consists of 2 classes for the API and 4 classes for the
> >> SPI.
> >>>>>>> The source can be found here.
> >>>>>>> https://github.com/struberg/javaConfig
> >>>>>>>
> >>>>>>> And that’s pretty much it! There is not much more needed for it.
> >>>>>>>
> >>>>>>> I would love to move this to Geronimo. Simply because geronimo is
> >> kind
> >>>> of
> >>>>>>> an EE-commons for the ASF nowadays ;)
> >>>>>>>
> >>>>>>> wdyt?
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> N Oliver B. Fischer
> >>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>>> P +49 30 44793251
> >>>>> M +49 178 7903538
> >>>>> E o.b.fischer@swe-blog.net
> >>>>> S oliver.b.fischer
> >>>>> J oliver.b.fischer@jabber.org
> >>>>> X http://xing.to/obf
> >>>>>
> >>>>>
> >>>>
> >>
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
You know that this is a chicken-egg problem and that there are many projects which did totally different?
Oracle is also actively using the org.apache package names, whoops …
Lets stop that legal discussion. You are not a lawyer.
LieGrue,
strub
> Am 15.07.2016 um 00:57 schrieb Werner Keil <we...@gmail.com>:
>
> What's out on GitHub is taken for granted and can be forked and cloned as
> you know.
>
> A POC must not be called javax.config without a JSR ever being proposed or
> accepted just to try out "how it feels".
> When JSR 275 was stopped we took the ideas and working concepts to a new
> project "unitsofmeasurement.org" for almost 5 years, not just do a "rogue
> JSR".
> Only when JSR 363 was approved we reused the namespace.
>
> So as a POC call it "config" if you like but not "javax.config",
> "java.config" or "jdk.config" that implies a working JSR or parts of the
> JDK;-)
>
> Cheers
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
> | #DevOps | #EclipseUOMo
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
>
>
> On Fri, Jul 15, 2016 at 12:48 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
>>>
>>> Yes but neither at Apache nor elsewhere you can just go and declare "your
>>> JSR", this is unacceptable especially from the package space point.
>>> A JSR under "javax.something" is only allowed for an EG once a JSR was
>>> filed and approved by the Executive Committee.
>>>
>>> Mark is free to register any domain like "marksconfig.io" because .io is
>>> just hip now and used by everybody and declare that project on GitHub.
>>> If someone wishes to propose a new JSR, go ahead and do so under
>>> https://www.jcp.org/en/jsr/proposal but not like that ;-(
>>>
>>> Nobody did so, thus if it ever happened, any of the mentioned projects
>> may
>>> be listed as "initial contribution", inspiration or whatever, but simply
>>> throwing something out there under javax.config is unconstructive, just
>>> because you you're unhappy with either Apache Commons Config, Typesafe
>>> Config, Spring Config, DeltaSpike Config or Tamaya.
>>>
>>
>> It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
>> yet on details
>>
>>> Cheers,
>>> Werner
>>>
>>>
>>> On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>>> wrote:
>>>
>>>> Tamaya is far beyond a JSR in design and impl. It is a promishing
>> product
>>>> but too opponiated to be a JSR today IMO. Config needs something
>> smaller.
>>>> DS solution is a pretty good start for that.
>>>>
>>>> Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net>
>> a
>>>> écrit :
>>>>
>>>>> I a little bit confused. As I know our common goal is to establish a
>>>>> configuration JSR based on Tamaya. I wouldn't like to see here a race
>> for
>>>>> the one how submits its JSR first....
>>>>>
>>>>>
>>>>> Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
>>>>>
>>>>>> +1 Mark if it can be a real JSR otherwise we can stick with DS and
>>>> Tamaya
>>>>>> for asf.
>>>>>>
>>>>>>
>>>>>> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
>>>> écrit :
>>>>>>
>>>>>> Doesn't this overlap with another project you've been involved with,
>>>>>>> Tamaya?
>>>>>>>
>>>>>>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de>
>> wrote:
>>>>>>>
>>>>>>> Hi folks!
>>>>>>>
>>>>>>> I’ve started to extract the configuration work I’ve done in OWB,
>>>> MyFaces
>>>>>>> and DeltaSpike into an own little project.
>>>>>>> For the MyFaces and DeltaSpike parts I got help from ASF member
>> Gerhard
>>>>>>> Petracek.
>>>>>>>
>>>>>>> My goal is to establish an own JSR for configuration.
>>>>>>>
>>>>>>> So far it consists of 2 classes for the API and 4 classes for the
>> SPI.
>>>>>>> The source can be found here.
>>>>>>> https://github.com/struberg/javaConfig
>>>>>>>
>>>>>>> And that’s pretty much it! There is not much more needed for it.
>>>>>>>
>>>>>>> I would love to move this to Geronimo. Simply because geronimo is
>> kind
>>>> of
>>>>>>> an EE-commons for the ASF nowadays ;)
>>>>>>>
>>>>>>> wdyt?
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> N Oliver B. Fischer
>>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>>> P +49 30 44793251
>>>>> M +49 178 7903538
>>>>> E o.b.fischer@swe-blog.net
>>>>> S oliver.b.fischer
>>>>> J oliver.b.fischer@jabber.org
>>>>> X http://xing.to/obf
>>>>>
>>>>>
>>>>
>>
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de>.
You know that this is a chicken-egg problem and that there are many projects which did totally different?
Oracle is also actively using the org.apache package names, whoops …
Lets stop that legal discussion. You are not a lawyer.
LieGrue,
strub
> Am 15.07.2016 um 00:57 schrieb Werner Keil <we...@gmail.com>:
>
> What's out on GitHub is taken for granted and can be forked and cloned as
> you know.
>
> A POC must not be called javax.config without a JSR ever being proposed or
> accepted just to try out "how it feels".
> When JSR 275 was stopped we took the ideas and working concepts to a new
> project "unitsofmeasurement.org" for almost 5 years, not just do a "rogue
> JSR".
> Only when JSR 363 was approved we reused the namespace.
>
> So as a POC call it "config" if you like but not "javax.config",
> "java.config" or "jdk.config" that implies a working JSR or parts of the
> JDK;-)
>
> Cheers
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
> | #DevOps | #EclipseUOMo
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
>
>
> On Fri, Jul 15, 2016 at 12:48 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
>>>
>>> Yes but neither at Apache nor elsewhere you can just go and declare "your
>>> JSR", this is unacceptable especially from the package space point.
>>> A JSR under "javax.something" is only allowed for an EG once a JSR was
>>> filed and approved by the Executive Committee.
>>>
>>> Mark is free to register any domain like "marksconfig.io" because .io is
>>> just hip now and used by everybody and declare that project on GitHub.
>>> If someone wishes to propose a new JSR, go ahead and do so under
>>> https://www.jcp.org/en/jsr/proposal but not like that ;-(
>>>
>>> Nobody did so, thus if it ever happened, any of the mentioned projects
>> may
>>> be listed as "initial contribution", inspiration or whatever, but simply
>>> throwing something out there under javax.config is unconstructive, just
>>> because you you're unhappy with either Apache Commons Config, Typesafe
>>> Config, Spring Config, DeltaSpike Config or Tamaya.
>>>
>>
>> It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
>> yet on details
>>
>>> Cheers,
>>> Werner
>>>
>>>
>>> On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>>> wrote:
>>>
>>>> Tamaya is far beyond a JSR in design and impl. It is a promishing
>> product
>>>> but too opponiated to be a JSR today IMO. Config needs something
>> smaller.
>>>> DS solution is a pretty good start for that.
>>>>
>>>> Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net>
>> a
>>>> écrit :
>>>>
>>>>> I a little bit confused. As I know our common goal is to establish a
>>>>> configuration JSR based on Tamaya. I wouldn't like to see here a race
>> for
>>>>> the one how submits its JSR first....
>>>>>
>>>>>
>>>>> Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
>>>>>
>>>>>> +1 Mark if it can be a real JSR otherwise we can stick with DS and
>>>> Tamaya
>>>>>> for asf.
>>>>>>
>>>>>>
>>>>>> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
>>>> écrit :
>>>>>>
>>>>>> Doesn't this overlap with another project you've been involved with,
>>>>>>> Tamaya?
>>>>>>>
>>>>>>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de>
>> wrote:
>>>>>>>
>>>>>>> Hi folks!
>>>>>>>
>>>>>>> I’ve started to extract the configuration work I’ve done in OWB,
>>>> MyFaces
>>>>>>> and DeltaSpike into an own little project.
>>>>>>> For the MyFaces and DeltaSpike parts I got help from ASF member
>> Gerhard
>>>>>>> Petracek.
>>>>>>>
>>>>>>> My goal is to establish an own JSR for configuration.
>>>>>>>
>>>>>>> So far it consists of 2 classes for the API and 4 classes for the
>> SPI.
>>>>>>> The source can be found here.
>>>>>>> https://github.com/struberg/javaConfig
>>>>>>>
>>>>>>> And that’s pretty much it! There is not much more needed for it.
>>>>>>>
>>>>>>> I would love to move this to Geronimo. Simply because geronimo is
>> kind
>>>> of
>>>>>>> an EE-commons for the ASF nowadays ;)
>>>>>>>
>>>>>>> wdyt?
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>>> N Oliver B. Fischer
>>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>>> P +49 30 44793251
>>>>> M +49 178 7903538
>>>>> E o.b.fischer@swe-blog.net
>>>>> S oliver.b.fischer
>>>>> J oliver.b.fischer@jabber.org
>>>>> X http://xing.to/obf
>>>>>
>>>>>
>>>>
>>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
What's out on GitHub is taken for granted and can be forked and cloned as
you know.
A POC must not be called javax.config without a JSR ever being proposed or
accepted just to try out "how it feels".
When JSR 275 was stopped we took the ideas and working concepts to a new
project "unitsofmeasurement.org" for almost 5 years, not just do a "rogue
JSR".
Only when JSR 363 was approved we reused the namespace.
So as a POC call it "config" if you like but not "javax.config",
"java.config" or "jdk.config" that implies a working JSR or parts of the
JDK;-)
Cheers
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Fri, Jul 15, 2016 at 12:48 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
> >
> > Yes but neither at Apache nor elsewhere you can just go and declare "your
> > JSR", this is unacceptable especially from the package space point.
> > A JSR under "javax.something" is only allowed for an EG once a JSR was
> > filed and approved by the Executive Committee.
> >
> > Mark is free to register any domain like "marksconfig.io" because .io is
> > just hip now and used by everybody and declare that project on GitHub.
> > If someone wishes to propose a new JSR, go ahead and do so under
> > https://www.jcp.org/en/jsr/proposal but not like that ;-(
> >
> > Nobody did so, thus if it ever happened, any of the mentioned projects
> may
> > be listed as "initial contribution", inspiration or whatever, but simply
> > throwing something out there under javax.config is unconstructive, just
> > because you you're unhappy with either Apache Commons Config, Typesafe
> > Config, Spring Config, DeltaSpike Config or Tamaya.
> >
>
> It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
> yet on details
>
> > Cheers,
> > Werner
> >
> >
> > On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Tamaya is far beyond a JSR in design and impl. It is a promishing
> product
> > > but too opponiated to be a JSR today IMO. Config needs something
> smaller.
> > > DS solution is a pretty good start for that.
> > >
> > > Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net>
> a
> > > écrit :
> > >
> > > > I a little bit confused. As I know our common goal is to establish a
> > > > configuration JSR based on Tamaya. I wouldn't like to see here a race
> for
> > > > the one how submits its JSR first....
> > > >
> > > >
> > > > Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> > > >
> > > >> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> > > Tamaya
> > > >> for asf.
> > > >>
> > > >>
> > > >> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> > > écrit :
> > > >>
> > > >> Doesn't this overlap with another project you've been involved with,
> > > >>> Tamaya?
> > > >>>
> > > >>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de>
> wrote:
> > > >>>
> > > >>> Hi folks!
> > > >>>
> > > >>> I’ve started to extract the configuration work I’ve done in OWB,
> > > MyFaces
> > > >>> and DeltaSpike into an own little project.
> > > >>> For the MyFaces and DeltaSpike parts I got help from ASF member
> Gerhard
> > > >>> Petracek.
> > > >>>
> > > >>> My goal is to establish an own JSR for configuration.
> > > >>>
> > > >>> So far it consists of 2 classes for the API and 4 classes for the
> SPI.
> > > >>> The source can be found here.
> > > >>> https://github.com/struberg/javaConfig
> > > >>>
> > > >>> And that’s pretty much it! There is not much more needed for it.
> > > >>>
> > > >>> I would love to move this to Geronimo. Simply because geronimo is
> kind
> > > of
> > > >>> an EE-commons for the ASF nowadays ;)
> > > >>>
> > > >>> wdyt?
> > > >>>
> > > >>> LieGrue,
> > > >>> strub
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > > --
> > > > N Oliver B. Fischer
> > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > P +49 30 44793251
> > > > M +49 178 7903538
> > > > E o.b.fischer@swe-blog.net
> > > > S oliver.b.fischer
> > > > J oliver.b.fischer@jabber.org
> > > > X http://xing.to/obf
> > > >
> > > >
> > >
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
What's out on GitHub is taken for granted and can be forked and cloned as
you know.
A POC must not be called javax.config without a JSR ever being proposed or
accepted just to try out "how it feels".
When JSR 275 was stopped we took the ideas and working concepts to a new
project "unitsofmeasurement.org" for almost 5 years, not just do a "rogue
JSR".
Only when JSR 363 was approved we reused the namespace.
So as a POC call it "config" if you like but not "javax.config",
"java.config" or "jdk.config" that implies a working JSR or parts of the
JDK;-)
Cheers
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Fri, Jul 15, 2016 at 12:48 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
> >
> > Yes but neither at Apache nor elsewhere you can just go and declare "your
> > JSR", this is unacceptable especially from the package space point.
> > A JSR under "javax.something" is only allowed for an EG once a JSR was
> > filed and approved by the Executive Committee.
> >
> > Mark is free to register any domain like "marksconfig.io" because .io is
> > just hip now and used by everybody and declare that project on GitHub.
> > If someone wishes to propose a new JSR, go ahead and do so under
> > https://www.jcp.org/en/jsr/proposal but not like that ;-(
> >
> > Nobody did so, thus if it ever happened, any of the mentioned projects
> may
> > be listed as "initial contribution", inspiration or whatever, but simply
> > throwing something out there under javax.config is unconstructive, just
> > because you you're unhappy with either Apache Commons Config, Typesafe
> > Config, Spring Config, DeltaSpike Config or Tamaya.
> >
>
> It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
> yet on details
>
> > Cheers,
> > Werner
> >
> >
> > On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Tamaya is far beyond a JSR in design and impl. It is a promishing
> product
> > > but too opponiated to be a JSR today IMO. Config needs something
> smaller.
> > > DS solution is a pretty good start for that.
> > >
> > > Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net>
> a
> > > écrit :
> > >
> > > > I a little bit confused. As I know our common goal is to establish a
> > > > configuration JSR based on Tamaya. I wouldn't like to see here a race
> for
> > > > the one how submits its JSR first....
> > > >
> > > >
> > > > Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> > > >
> > > >> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> > > Tamaya
> > > >> for asf.
> > > >>
> > > >>
> > > >> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> > > écrit :
> > > >>
> > > >> Doesn't this overlap with another project you've been involved with,
> > > >>> Tamaya?
> > > >>>
> > > >>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de>
> wrote:
> > > >>>
> > > >>> Hi folks!
> > > >>>
> > > >>> I’ve started to extract the configuration work I’ve done in OWB,
> > > MyFaces
> > > >>> and DeltaSpike into an own little project.
> > > >>> For the MyFaces and DeltaSpike parts I got help from ASF member
> Gerhard
> > > >>> Petracek.
> > > >>>
> > > >>> My goal is to establish an own JSR for configuration.
> > > >>>
> > > >>> So far it consists of 2 classes for the API and 4 classes for the
> SPI.
> > > >>> The source can be found here.
> > > >>> https://github.com/struberg/javaConfig
> > > >>>
> > > >>> And that’s pretty much it! There is not much more needed for it.
> > > >>>
> > > >>> I would love to move this to Geronimo. Simply because geronimo is
> kind
> > > of
> > > >>> an EE-commons for the ASF nowadays ;)
> > > >>>
> > > >>> wdyt?
> > > >>>
> > > >>> LieGrue,
> > > >>> strub
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > > --
> > > > N Oliver B. Fischer
> > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > P +49 30 44793251
> > > > M +49 178 7903538
> > > > E o.b.fischer@swe-blog.net
> > > > S oliver.b.fischer
> > > > J oliver.b.fischer@jabber.org
> > > > X http://xing.to/obf
> > > >
> > > >
> > >
>
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
>
> Yes but neither at Apache nor elsewhere you can just go and declare "your
> JSR", this is unacceptable especially from the package space point.
> A JSR under "javax.something" is only allowed for an EG once a JSR was
> filed and approved by the Executive Committee.
>
> Mark is free to register any domain like "marksconfig.io" because .io is
> just hip now and used by everybody and declare that project on GitHub.
> If someone wishes to propose a new JSR, go ahead and do so under
> https://www.jcp.org/en/jsr/proposal but not like that ;-(
>
> Nobody did so, thus if it ever happened, any of the mentioned projects may
> be listed as "initial contribution", inspiration or whatever, but simply
> throwing something out there under javax.config is unconstructive, just
> because you you're unhappy with either Apache Commons Config, Typesafe
> Config, Spring Config, DeltaSpike Config or Tamaya.
>
It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
yet on details
> Cheers,
> Werner
>
>
> On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
rmannibucau@gmail.com>
> wrote:
>
> > Tamaya is far beyond a JSR in design and impl. It is a promishing
product
> > but too opponiated to be a JSR today IMO. Config needs something
smaller.
> > DS solution is a pretty good start for that.
> >
> > Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net> a
> > écrit :
> >
> > > I a little bit confused. As I know our common goal is to establish a
> > > configuration JSR based on Tamaya. I wouldn't like to see here a race
for
> > > the one how submits its JSR first....
> > >
> > >
> > > Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> > >
> > >> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> > Tamaya
> > >> for asf.
> > >>
> > >>
> > >> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> > écrit :
> > >>
> > >> Doesn't this overlap with another project you've been involved with,
> > >>> Tamaya?
> > >>>
> > >>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> > >>>
> > >>> Hi folks!
> > >>>
> > >>> I’ve started to extract the configuration work I’ve done in OWB,
> > MyFaces
> > >>> and DeltaSpike into an own little project.
> > >>> For the MyFaces and DeltaSpike parts I got help from ASF member
Gerhard
> > >>> Petracek.
> > >>>
> > >>> My goal is to establish an own JSR for configuration.
> > >>>
> > >>> So far it consists of 2 classes for the API and 4 classes for the
SPI.
> > >>> The source can be found here.
> > >>> https://github.com/struberg/javaConfig
> > >>>
> > >>> And that’s pretty much it! There is not much more needed for it.
> > >>>
> > >>> I would love to move this to Geronimo. Simply because geronimo is
kind
> > of
> > >>> an EE-commons for the ASF nowadays ;)
> > >>>
> > >>> wdyt?
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>>
> > >>>
> > > --
> > > N Oliver B. Fischer
> > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > P +49 30 44793251
> > > M +49 178 7903538
> > > E o.b.fischer@swe-blog.net
> > > S oliver.b.fischer
> > > J oliver.b.fischer@jabber.org
> > > X http://xing.to/obf
> > >
> > >
> >
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 15 juil. 2016 00:46, "Werner Keil" <we...@gmail.com> a écrit :
>
> Yes but neither at Apache nor elsewhere you can just go and declare "your
> JSR", this is unacceptable especially from the package space point.
> A JSR under "javax.something" is only allowed for an EG once a JSR was
> filed and approved by the Executive Committee.
>
> Mark is free to register any domain like "marksconfig.io" because .io is
> just hip now and used by everybody and declare that project on GitHub.
> If someone wishes to propose a new JSR, go ahead and do so under
> https://www.jcp.org/en/jsr/proposal but not like that ;-(
>
> Nobody did so, thus if it ever happened, any of the mentioned projects may
> be listed as "initial contribution", inspiration or whatever, but simply
> throwing something out there under javax.config is unconstructive, just
> because you you're unhappy with either Apache Commons Config, Typesafe
> Config, Spring Config, DeltaSpike Config or Tamaya.
>
It is a proposal/poc. Let s keep focus on real topic and dont flame Mark
yet on details
> Cheers,
> Werner
>
>
> On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <
rmannibucau@gmail.com>
> wrote:
>
> > Tamaya is far beyond a JSR in design and impl. It is a promishing
product
> > but too opponiated to be a JSR today IMO. Config needs something
smaller.
> > DS solution is a pretty good start for that.
> >
> > Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net> a
> > écrit :
> >
> > > I a little bit confused. As I know our common goal is to establish a
> > > configuration JSR based on Tamaya. I wouldn't like to see here a race
for
> > > the one how submits its JSR first....
> > >
> > >
> > > Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> > >
> > >> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> > Tamaya
> > >> for asf.
> > >>
> > >>
> > >> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> > écrit :
> > >>
> > >> Doesn't this overlap with another project you've been involved with,
> > >>> Tamaya?
> > >>>
> > >>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> > >>>
> > >>> Hi folks!
> > >>>
> > >>> I’ve started to extract the configuration work I’ve done in OWB,
> > MyFaces
> > >>> and DeltaSpike into an own little project.
> > >>> For the MyFaces and DeltaSpike parts I got help from ASF member
Gerhard
> > >>> Petracek.
> > >>>
> > >>> My goal is to establish an own JSR for configuration.
> > >>>
> > >>> So far it consists of 2 classes for the API and 4 classes for the
SPI.
> > >>> The source can be found here.
> > >>> https://github.com/struberg/javaConfig
> > >>>
> > >>> And that’s pretty much it! There is not much more needed for it.
> > >>>
> > >>> I would love to move this to Geronimo. Simply because geronimo is
kind
> > of
> > >>> an EE-commons for the ASF nowadays ;)
> > >>>
> > >>> wdyt?
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>>
> > >>>
> > > --
> > > N Oliver B. Fischer
> > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > P +49 30 44793251
> > > M +49 178 7903538
> > > E o.b.fischer@swe-blog.net
> > > S oliver.b.fischer
> > > J oliver.b.fischer@jabber.org
> > > X http://xing.to/obf
> > >
> > >
> >
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Yes but neither at Apache nor elsewhere you can just go and declare "your
JSR", this is unacceptable especially from the package space point.
A JSR under "javax.something" is only allowed for an EG once a JSR was
filed and approved by the Executive Committee.
Mark is free to register any domain like "marksconfig.io" because .io is
just hip now and used by everybody and declare that project on GitHub.
If someone wishes to propose a new JSR, go ahead and do so under
https://www.jcp.org/en/jsr/proposal but not like that ;-(
Nobody did so, thus if it ever happened, any of the mentioned projects may
be listed as "initial contribution", inspiration or whatever, but simply
throwing something out there under javax.config is unconstructive, just
because you you're unhappy with either Apache Commons Config, Typesafe
Config, Spring Config, DeltaSpike Config or Tamaya.
Cheers,
Werner
On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Tamaya is far beyond a JSR in design and impl. It is a promishing product
> but too opponiated to be a JSR today IMO. Config needs something smaller.
> DS solution is a pretty good start for that.
>
> Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
> > I a little bit confused. As I know our common goal is to establish a
> > configuration JSR based on Tamaya. I wouldn't like to see here a race for
> > the one how submits its JSR first....
> >
> >
> > Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> >
> >> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> Tamaya
> >> for asf.
> >>
> >>
> >> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> écrit :
> >>
> >> Doesn't this overlap with another project you've been involved with,
> >>> Tamaya?
> >>>
> >>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> >>>
> >>> Hi folks!
> >>>
> >>> I’ve started to extract the configuration work I’ve done in OWB,
> MyFaces
> >>> and DeltaSpike into an own little project.
> >>> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
> >>> Petracek.
> >>>
> >>> My goal is to establish an own JSR for configuration.
> >>>
> >>> So far it consists of 2 classes for the API and 4 classes for the SPI.
> >>> The source can be found here.
> >>> https://github.com/struberg/javaConfig
> >>>
> >>> And that’s pretty much it! There is not much more needed for it.
> >>>
> >>> I would love to move this to Geronimo. Simply because geronimo is kind
> of
> >>> an EE-commons for the ASF nowadays ;)
> >>>
> >>> wdyt?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
Yes but neither at Apache nor elsewhere you can just go and declare "your
JSR", this is unacceptable especially from the package space point.
A JSR under "javax.something" is only allowed for an EG once a JSR was
filed and approved by the Executive Committee.
Mark is free to register any domain like "marksconfig.io" because .io is
just hip now and used by everybody and declare that project on GitHub.
If someone wishes to propose a new JSR, go ahead and do so under
https://www.jcp.org/en/jsr/proposal but not like that ;-(
Nobody did so, thus if it ever happened, any of the mentioned projects may
be listed as "initial contribution", inspiration or whatever, but simply
throwing something out there under javax.config is unconstructive, just
because you you're unhappy with either Apache Commons Config, Typesafe
Config, Spring Config, DeltaSpike Config or Tamaya.
Cheers,
Werner
On Fri, Jul 15, 2016 at 12:36 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Tamaya is far beyond a JSR in design and impl. It is a promishing product
> but too opponiated to be a JSR today IMO. Config needs something smaller.
> DS solution is a pretty good start for that.
>
> Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
> > I a little bit confused. As I know our common goal is to establish a
> > configuration JSR based on Tamaya. I wouldn't like to see here a race for
> > the one how submits its JSR first....
> >
> >
> > Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> >
> >> +1 Mark if it can be a real JSR otherwise we can stick with DS and
> Tamaya
> >> for asf.
> >>
> >>
> >> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a
> écrit :
> >>
> >> Doesn't this overlap with another project you've been involved with,
> >>> Tamaya?
> >>>
> >>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> >>>
> >>> Hi folks!
> >>>
> >>> I’ve started to extract the configuration work I’ve done in OWB,
> MyFaces
> >>> and DeltaSpike into an own little project.
> >>> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
> >>> Petracek.
> >>>
> >>> My goal is to establish an own JSR for configuration.
> >>>
> >>> So far it consists of 2 classes for the API and 4 classes for the SPI.
> >>> The source can be found here.
> >>> https://github.com/struberg/javaConfig
> >>>
> >>> And that’s pretty much it! There is not much more needed for it.
> >>>
> >>> I would love to move this to Geronimo. Simply because geronimo is kind
> of
> >>> an EE-commons for the ASF nowadays ;)
> >>>
> >>> wdyt?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Tamaya is far beyond a JSR in design and impl. It is a promishing product
but too opponiated to be a JSR today IMO. Config needs something smaller.
DS solution is a pretty good start for that.
Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> I a little bit confused. As I know our common goal is to establish a
> configuration JSR based on Tamaya. I wouldn't like to see here a race for
> the one how submits its JSR first....
>
>
> Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
>
>> +1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
>> for asf.
>>
>>
>> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a écrit :
>>
>> Doesn't this overlap with another project you've been involved with,
>>> Tamaya?
>>>
>>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>>>
>>> Hi folks!
>>>
>>> I’ve started to extract the configuration work I’ve done in OWB, MyFaces
>>> and DeltaSpike into an own little project.
>>> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
>>> Petracek.
>>>
>>> My goal is to establish an own JSR for configuration.
>>>
>>> So far it consists of 2 classes for the API and 4 classes for the SPI.
>>> The source can be found here.
>>> https://github.com/struberg/javaConfig
>>>
>>> And that’s pretty much it! There is not much more needed for it.
>>>
>>> I would love to move this to Geronimo. Simply because geronimo is kind of
>>> an EE-commons for the ASF nowadays ;)
>>>
>>> wdyt?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Tamaya is far beyond a JSR in design and impl. It is a promishing product
but too opponiated to be a JSR today IMO. Config needs something smaller.
DS solution is a pretty good start for that.
Le 15 juil. 2016 00:33, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> I a little bit confused. As I know our common goal is to establish a
> configuration JSR based on Tamaya. I wouldn't like to see here a race for
> the one how submits its JSR first....
>
>
> Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
>
>> +1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
>> for asf.
>>
>>
>> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a écrit :
>>
>> Doesn't this overlap with another project you've been involved with,
>>> Tamaya?
>>>
>>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>>>
>>> Hi folks!
>>>
>>> I’ve started to extract the configuration work I’ve done in OWB, MyFaces
>>> and DeltaSpike into an own little project.
>>> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
>>> Petracek.
>>>
>>> My goal is to establish an own JSR for configuration.
>>>
>>> So far it consists of 2 classes for the API and 4 classes for the SPI.
>>> The source can be found here.
>>> https://github.com/struberg/javaConfig
>>>
>>> And that’s pretty much it! There is not much more needed for it.
>>>
>>> I would love to move this to Geronimo. Simply because geronimo is kind of
>>> an EE-commons for the ASF nowadays ;)
>>>
>>> wdyt?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I a little bit confused. As I know our common goal is to establish a
configuration JSR based on Tamaya. I wouldn't like to see here a race
for the one how submits its JSR first....
Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> +1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
> for asf.
>
>
> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a �crit :
>
>> Doesn't this overlap with another project you've been involved with,
>> Tamaya?
>>
>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>>
>> Hi folks!
>>
>> I\u2019ve started to extract the configuration work I\u2019ve done in OWB, MyFaces
>> and DeltaSpike into an own little project.
>> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
>> Petracek.
>>
>> My goal is to establish an own JSR for configuration.
>>
>> So far it consists of 2 classes for the API and 4 classes for the SPI.
>> The source can be found here.
>> https://github.com/struberg/javaConfig
>>
>> And that\u2019s pretty much it! There is not much more needed for it.
>>
>> I would love to move this to Geronimo. Simply because geronimo is kind of
>> an EE-commons for the ASF nowadays ;)
>>
>> wdyt?
>>
>> LieGrue,
>> strub
>>
>>
>>
--
N Oliver B. Fischer
A Sch�nhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
This is getting a bit confusing. Now we got
- Apache Commons Config 2
- Apache DeltaSpike Config (also with Mark being heavily involved)
- Apache Tamaya based on
- Java Configuration on GitHub (https://github.com/java-config)
- Apache Geronimo Config ?
What's largely irritating and not constructive at all is, that Mark calls
his stuff "javax.config", there has neither been a JSR filed nor anything
else.
I announced to the JCP EC when asked about "Ideas for new JSRs" that aside
from other ideas like NoSQL Conguration management was among those we'd
hope to revisit.
Anatole was invited to talk about Tamaya or configuration in general, but
no JSR has been filed yet, therefore this "rogue" JSR by a self-declared
Spec Lead is not sanctioned by the JCP and must not be called
"javax.config" until at JSR was proposed and created.
Cheers,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Fri, Jul 15, 2016 at 12:24 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> +1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
> for asf.
>
>
> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a écrit :
>
> > Doesn't this overlap with another project you've been involved with,
> > Tamaya?
> >
> > On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> >
> > Hi folks!
> >
> > I’ve started to extract the configuration work I’ve done in OWB, MyFaces
> > and DeltaSpike into an own little project.
> > For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
> > Petracek.
> >
> > My goal is to establish an own JSR for configuration.
> >
> > So far it consists of 2 classes for the API and 4 classes for the SPI.
> > The source can be found here.
> > https://github.com/struberg/javaConfig
> >
> > And that’s pretty much it! There is not much more needed for it.
> >
> > I would love to move this to Geronimo. Simply because geronimo is kind of
> > an EE-commons for the ASF nowadays ;)
> >
> > wdyt?
> >
> > LieGrue,
> > strub
> >
> >
> >
>
Re: Configuration for Java SE and Java EE JSR
Posted by Werner Keil <we...@gmail.com>.
This is getting a bit confusing. Now we got
- Apache Commons Config 2
- Apache DeltaSpike Config (also with Mark being heavily involved)
- Apache Tamaya based on
- Java Configuration on GitHub (https://github.com/java-config)
- Apache Geronimo Config ?
What's largely irritating and not constructive at all is, that Mark calls
his stuff "javax.config", there has neither been a JSR filed nor anything
else.
I announced to the JCP EC when asked about "Ideas for new JSRs" that aside
from other ideas like NoSQL Conguration management was among those we'd
hope to revisit.
Anatole was invited to talk about Tamaya or configuration in general, but
no JSR has been filed yet, therefore this "rogue" JSR by a self-declared
Spec Lead is not sanctioned by the JCP and must not be called
"javax.config" until at JSR was proposed and created.
Cheers,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Fri, Jul 15, 2016 at 12:24 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> +1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
> for asf.
>
>
> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a écrit :
>
> > Doesn't this overlap with another project you've been involved with,
> > Tamaya?
> >
> > On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> >
> > Hi folks!
> >
> > I’ve started to extract the configuration work I’ve done in OWB, MyFaces
> > and DeltaSpike into an own little project.
> > For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
> > Petracek.
> >
> > My goal is to establish an own JSR for configuration.
> >
> > So far it consists of 2 classes for the API and 4 classes for the SPI.
> > The source can be found here.
> > https://github.com/struberg/javaConfig
> >
> > And that’s pretty much it! There is not much more needed for it.
> >
> > I would love to move this to Geronimo. Simply because geronimo is kind of
> > an EE-commons for the ASF nowadays ;)
> >
> > wdyt?
> >
> > LieGrue,
> > strub
> >
> >
> >
>
Re: Configuration for Java SE and Java EE JSR
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I a little bit confused. As I know our common goal is to establish a
configuration JSR based on Tamaya. I wouldn't like to see here a race
for the one how submits its JSR first....
Am 15.07.16 um 00:24 schrieb Romain Manni-Bucau:
> +1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
> for asf.
>
>
> Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a �crit :
>
>> Doesn't this overlap with another project you've been involved with,
>> Tamaya?
>>
>> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>>
>> Hi folks!
>>
>> I\u2019ve started to extract the configuration work I\u2019ve done in OWB, MyFaces
>> and DeltaSpike into an own little project.
>> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
>> Petracek.
>>
>> My goal is to establish an own JSR for configuration.
>>
>> So far it consists of 2 classes for the API and 4 classes for the SPI.
>> The source can be found here.
>> https://github.com/struberg/javaConfig
>>
>> And that\u2019s pretty much it! There is not much more needed for it.
>>
>> I would love to move this to Geronimo. Simply because geronimo is kind of
>> an EE-commons for the ASF nowadays ;)
>>
>> wdyt?
>>
>> LieGrue,
>> strub
>>
>>
>>
--
N Oliver B. Fischer
A Sch�nhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
for asf.
Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a écrit :
> Doesn't this overlap with another project you've been involved with,
> Tamaya?
>
> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces
> and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
> Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of
> an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
>
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de>.
Tamaya is nowadays quite far from a smallish solution but a very complex system.
LieGrue,
Strub
> Am 15.07.2016 um 00:20 schrieb John D. Ament <jo...@apache.org>:
>
> Doesn't this overlap with another project you've been involved with, Tamaya?
>
>
> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
>
Re: Configuration for Java SE and Java EE JSR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 Mark if it can be a real JSR otherwise we can stick with DS and Tamaya
for asf.
Le 15 juil. 2016 00:20, "John D. Ament" <jo...@apache.org> a écrit :
> Doesn't this overlap with another project you've been involved with,
> Tamaya?
>
> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces
> and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
> Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of
> an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
>
>
>
Re: Configuration for Java SE and Java EE JSR
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Tamaya is nowadays quite far from a smallish solution but a very complex system.
LieGrue,
Strub
> Am 15.07.2016 um 00:20 schrieb John D. Ament <jo...@apache.org>:
>
> Doesn't this overlap with another project you've been involved with, Tamaya?
>
>
> On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> Hi folks!
>
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard Petracek.
>
> My goal is to establish an own JSR for configuration.
>
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
>
> And that’s pretty much it! There is not much more needed for it.
>
> I would love to move this to Geronimo. Simply because geronimo is kind of an EE-commons for the ASF nowadays ;)
>
> wdyt?
>
> LieGrue,
> strub
>
Re: Configuration for Java SE and Java EE JSR
Posted by "John D. Ament" <jo...@apache.org>.
Doesn't this overlap with another project you've been involved with, Tamaya?
On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
Hi folks!
I’ve started to extract the configuration work I’ve done in OWB, MyFaces
and DeltaSpike into an own little project.
For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
Petracek.
My goal is to establish an own JSR for configuration.
So far it consists of 2 classes for the API and 4 classes for the SPI.
The source can be found here.
https://github.com/struberg/javaConfig
And that’s pretty much it! There is not much more needed for it.
I would love to move this to Geronimo. Simply because geronimo is kind of
an EE-commons for the ASF nowadays ;)
wdyt?
LieGrue,
strub
Re: Configuration for Java SE and Java EE JSR
Posted by "John D. Ament" <jo...@apache.org>.
Doesn't this overlap with another project you've been involved with, Tamaya?
On Jul 14, 2016 6:10 PM, "Mark Struberg" <st...@yahoo.de> wrote:
Hi folks!
I’ve started to extract the configuration work I’ve done in OWB, MyFaces
and DeltaSpike into an own little project.
For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard
Petracek.
My goal is to establish an own JSR for configuration.
So far it consists of 2 classes for the API and 4 classes for the SPI.
The source can be found here.
https://github.com/struberg/javaConfig
And that’s pretty much it! There is not much more needed for it.
I would love to move this to Geronimo. Simply because geronimo is kind of
an EE-commons for the ASF nowadays ;)
wdyt?
LieGrue,
strub