Re: [jira] [Commented] (TAMAYA-394) Fix existing sonar warnings after integrating with SonarCloud

[Werner Keil]

Isn't Tamaya going to be ramped down?

Werner



On Fri, Jul 3, 2020 at 10:11 PM ASF subversion and git services (Jira) <
j...@apache.org> wrote:

>
> [
> https://issues.apache.org/jira/browse/TAMAYA-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150926#comment-17150926
> ]
>
> ASF subversion and git services commented on TAMAYA-394:
> 
>
> Commit 059cbec1b56ccc77a6f0f12db18fe0385ecee69a in
> incubator-tamaya-extensions's branch refs/heads/feature/TAMAYA-394lombok
> from Hugo Hirsch
> [
> https://gitbox.apache.org/repos/asf?p=incubator-tamaya-extensions.git;h=059cbec
> ]
>
> TAMAYA-394: WIP
>
>
> > Fix existing sonar warnings after integrating with SonarCloud
> > -
> >
> > Key: TAMAYA-394
> > URL: https://issues.apache.org/jira/browse/TAMAYA-394
> > Project: Tamaya
> >  Issue Type: Improvement
> >Affects Versions: 0.4-incubating
> >Reporter: Philipp Ottlinger
> >Priority: Major
> >  Time Spent: 2h
> >  Remaining Estimate: 0h
> >
> > After integrating with SonarCloud fix all existing warnings/problems in
> all Tamaya-repos.
> >  * (/) [https://sonarcloud.io/dashboard?id=apache_incubator-tamaya]
> >  * [https://sonarcloud.io/dashboard?id=apache_incubator-tamaya-sandbox]
> >  * [(/)
> https://sonarcloud.io/dashboard?id=apache_incubator-tamaya-extensions|https://sonarcloud.io/dashboard?id=apache_incubator-tamaya-extensions
> ]
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>

Re: [NOTICE] Apache Tamaya is retiring - what next

[Werner Keil]

Anatole/all,

Not sure, if the list is working or turned off, but I forked every
repository into  https://github.com/java-config now.
I also archived the https://github.com/java-config/tamaya-export repository
because that makes no sense any more and was unchanged for the last 6 years
anyway.

Whether
https://github.com/java-config/tamaya
or
https://github.com/java-config/tamaya-sandbox
are allowed to be used depends very much if the name "Tamaya" could even be
used outside Apache Foundation?

There was a similar situation with DeviceMap and neither the fork by a
former committer who had other ideas but failed because nobody even forked
his stuff or contributed, nor the original project OpenDDR which is doing
quite well (anything between 1k and 100k downloads monthly  from the DDR
device data repo) would use the old Apache project name.
I don't know the precise rules, but unless e.g. similar to "Jakarta" Apache
Foundation granted us to keep using the name "Tamaya" we probably have to
abandon it and find a new one.


Werner




On Thu, Apr 30, 2020 at 11:20 PM Werner Keil  wrote:

> Hi,
>
> I also moved but it's already done, so I should be able to help sooner.
>
> Cheers,
>
> Werner
>
>
>
>
> On Thu, Apr 30, 2020 at 11:18 PM P. Ottlinger 
> wrote:
>
>> Hi all,
>>
>> as I'm in the middle of moving I won't be able to do that much until end
>> of June, but my github id is "ottlinger".
>>
>> Thanks and stay happy everybody!
>>
>> Cheers,
>> Phil
>>
>

Re: [NOTICE] Apache Tamaya is retiring - what next

[Werner Keil]

Hi,

I also moved but it's already done, so I should be able to help sooner.

Cheers,

Werner




On Thu, Apr 30, 2020 at 11:18 PM P. Ottlinger  wrote:

> Hi all,
>
> as I'm in the middle of moving I won't be able to do that much until end
> of June, but my github id is "ottlinger".
>
> Thanks and stay happy everybody!
>
> Cheers,
> Phil
>

Re: [NOTICE] Apache Tamaya is retiring - what next

[Werner Keil]

John/all,

Thanks for the update. I believe Philip already asked about that and
Anatole who owns the JavaConfig organization should be able to give those
who are willing to help admin or push access.
I am also happy to help, so please unless I already have could you give me
the necessary access?

Regards,

Werner



On Thu, Apr 30, 2020 at 2:29 PM John D. Ament  wrote:

> Hi all,
>
> Apache Tamaya has successfully completed incubation leading to their
> retirement from Apache.  In the coming days, this mailing list and other
> mailing lists for the project will be marked read only.  All repositories
> will be locked as well.
>
> I know there was an ask to move the repos back to their original home.  To
> do that, please file an infra ticket requesting the repos be transferred
> back.  They will work with you on the transfer process, however it must be
> done by the owner of the github project that will be taking ownership of
> the repositories.
>
> I wish you all the best
>
> John
>

Re: [VOTE] Retire Tamaya and migrate repositories to Github as they are

[Werner Keil]

It looks like William has sent it to both lists, everyone else must have
voted on dev.

Werner




On Thu, Apr 23, 2020 at 4:36 AM John D. Ament  wrote:

> Hi all
>
> Please note the mixed public/private lists.
>
> Looks like the vote passed, does that mean it's time to move it to the IPMC
> to vote?
>
> Thanks,
>
> John
>
>
> On Thu, Apr 16, 2020 at 5:28 AM P. Ottlinger 
> wrote:
>
> > Hi *,
> >
> > following our discussions in January and February 2020 I propose to
> > terminate/retire Apache Tamaya podling and move all repositories over to
> > Github and remove all references to Apache Software Foundation after
> that.
> >
> > Vote is open until 2020-04-20.
> >
> > [ ] +1 Please proceed with the steps above to retire Tamaya.
> > [ ] -1 No, let's keep Tamaya where it is and try to graduate.
> > [ ] 0 I don't mind
> >
> > Thanks,
> > Phil
> >
>

Re: [VOTE] Retire Tamaya and migrate repositories to Github as they are

[Werner Keil]

William you probably joined a little late, but I would not consider it a
chance to contribute to an official Jakarta EE configuration standard,
either directly or indirectly via MP Config.

Given most of that is also under the Apache license all it takes for those
who would like to contribute to Jakarta EE or Eclipse MicroProfile is an
ECA (pretty similar to the same agreement at Apache Foundation)

Werner




On Sat, Apr 18, 2020 at 12:08 AM  wrote:

> +1
>
> :-/
>
> 
> From: P. Ottlinger 
> Sent: Thursday, April 16, 2020 4:28 AM
> To: dev@tamaya.incubator.apache.org; priv...@tamaya.incubator.apache.org
> Subject: [VOTE] Retire Tamaya and migrate repositories to Github as they
> are
>
> Hi *,
>
> following our discussions in January and February 2020 I propose to
> terminate/retire Apache Tamaya podling and move all repositories over to
> Github and remove all references to Apache Software Foundation after that.
>
> Vote is open until 2020-04-20.
>
> [ ] +1 Please proceed with the steps above to retire Tamaya.
> [ ] -1 No, let's keep Tamaya where it is and try to graduate.
> [ ] 0 I don't mind
>
> Thanks,
> Phil
>

Re: [VOTE] Retire Tamaya and migrate repositories to Github as they are

[Werner Keil]

+1

Werner




On Thu, Apr 16, 2020 at 11:29 AM P. Ottlinger  wrote:

> Am 16.04.20 um 11:28 schrieb P. Ottlinger:
> > Hi *,
> >
> > following our discussions in January and February 2020 I propose to
> > terminate/retire Apache Tamaya podling and move all repositories over to
> > Github and remove all references to Apache Software Foundation after
> that.
> >
> > Vote is open until 2020-04-20.
> >
> > [ ] +1 Please proceed with the steps above to retire Tamaya.
> > [ ] -1 No, let's keep Tamaya where it is and try to graduate.
> > [ ] 0 I don't mind
>
> +1
>
> Phil
>

Re: Podling Tamaya Report Reminder - May 2020

[Werner Keil]

Justin,

Thanks for the update. I believe it is a good and sensible move.
Those who were able to contribute and still wish to help the cause have the
opportunity to help the likes of Helidon, Quarkus or Eclipse MicroProfile
which in one or the other form is a likely candidate for inclusion into the
Jakarta EE platform.

Werner




On Thu, Apr 16, 2020 at 10:17 AM Justin Mclean  wrote:

> HI,
>
> > as there is not attic for Incubator projects - can we just move the
> > source code to a public github repo and continue there?
>
> You need to have a public discussion about it here and a lazy vote on the
> IPMC list first and there may be some question around trademarks if any are
> involved. [1]
>
> Thanks,
> Justin
>
> 1. https://incubator.apache.org/guides/retirement.html

Re: Tamaya's Future (was Re: Podling Tamaya Report Reminder - February 2020)

[Werner Keil]

Hi Anatole,

Thanks for the update, also about your future career step. Congratulations
on moving to IBM soon.
As we discussed, an incubating project does not get archived, but simply
deleted by Apache, correct me if I got that wrong?

So 1) would delete and destroy all of it. There may not be too many real
life use cases in production right now, but it demonstrated a few aspects
that e.g. Microprofile Config and other (not so cloud aware) config
solutions are still missing
 2) there seems nothing wrong with that, and the GH organization you
(Anatole) already created could be used for that.
There is a very outdated fork of Tamaya
https://github.com/java-config/incubator-tamaya (which would not go away
even if the repo at Apache did;-)
and the "seed" for Tamaya:  https://github.com/java-config/tamaya-export
Based on my experience I would at least declare the latter as archived and
make it read-only in GitHub (could you do that please or offer admin rights
to others in the organization?)
So maybe prior to ASF pulling the plug a "dump" may be created, but ideally
it should not be a fork but also migrated elsewhere. Reza (not the Jakarta
EE Ambassador) who also helped weather.com use OpenDDR/Devicemap (it's now
owned by IBM, but not sure, if it still uses W3C DDR or other device
recognition) forked the DeviceMap Java client to
https://github.com/TextGlass/java of course, it never saw any contributions
after 2015, so it's dead while OpenDDR data was downloaded around 150.000
times last year after more than twice that in 2018.

Unless we got a domain like javaconfig.org, we could always use
io.github.javaconfig.

Option 3) I am not sure, if e.g. the Apache Commons Config team was
interested, that is the only place I could see where parts of Tamaya may be
of interest.


Werner




On Mon, Feb 10, 2020 at 11:28 PM Anatole Tresch  wrote:

> Hi all
>
> as you all know I also started the discussion about Tamaya's future.
> Background is that I will move to IBM end of April 2020 and start as a
> Cloud Consultant. So I will not have too much time left for doing
> Java/programming.
> That does not mean that I would like to abandon this project completely,
> but for me it makes no sense keeping it up running in the current mode,
> unless some people really start to get into the code as well (it is not
> that complicated mostly).Moving it to GitHub does not solve the community
> issue, that is correct, but objective of the incubator is to build up a
> community, which I think was not possible. So I basically see the following
> options:
>
> 1) Retire everything (RIP)
> 2) Move everything to GitHub and see how things evolve.
> 3) See if the core part/API can be moved as a subproject somewhere in
> Apache and move the extensions to GitHub.
>
> J Anatole
>
>
> Am Mo., 10. Feb. 2020 um 22:46 Uhr schrieb P. Ottlinger <
> pottlin...@apache.org>:
>
> > Hi,
> >
> > Am 10.02.20 um 22:29 schrieb Oliver B. Fischer:
> > > But looking at the number of commits, Tamaya is dying.
> >
> > LOL - Anatole is and was the main contributor and committer -
> > this did not change over the period Tamaya is in incubating mode, IMHO.
> >
> > > What do you thing, does Tamaya currently provides anything usefull for
> > > users what is not provided by other frameworks?
> >
> > Most useful is a broad variety of extensions that allow Tamaya to be
> > used in various circumstances/environments - to my mind that's the
> > biggest pro.
> >
> > But we didn't gain any momentum to let the world know of this cool
> feature.
> >
> > Moving it to Github would only stop the ASF reporting schedule but does
> > not address the issue of a viable future.
> >
> > Just my 2ct,
> >
> > Phil
> >
> >
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>

Re: Tamaya's Future (was Re: Podling Tamaya Report Reminder - February 2020)

[Werner Keil]

I guess John knows best, what happens when you're no longer able to
contribute to a project:
https://github.com/eclipse/microprofile-rest-client/graphs/contributors If
it wasn't for IBM then MP Rest Client would be dead after he stopped
working on it around 2 years ago.

Same for Config btw
https://github.com/eclipse/microprofile-config/graphs/contributors but at
least Emily/IBM also helped out here a bit recently.
Whether MP Config really has a chance of becoming an integral part of
Jakarta EE (which would be a key to further participation and success)
remains to be seen, but it is a possible place to continue contributing if
Tamaya was to stop.
I mentioed others, Helidon
https://github.com/oracle/helidon/graphs/contributors is clearly a huge
success and an active community also with an interesting and promising
configuration module...


Werner



On Mon, Feb 10, 2020 at 10:46 PM P. Ottlinger  wrote:

> Hi,
>
> Am 10.02.20 um 22:29 schrieb Oliver B. Fischer:
> > But looking at the number of commits, Tamaya is dying.
>
> LOL - Anatole is and was the main contributor and committer -
> this did not change over the period Tamaya is in incubating mode, IMHO.
>
> > What do you thing, does Tamaya currently provides anything usefull for
> > users what is not provided by other frameworks?
>
> Most useful is a broad variety of extensions that allow Tamaya to be
> used in various circumstances/environments - to my mind that's the
> biggest pro.
>
> But we didn't gain any momentum to let the world know of this cool feature.
>
> Moving it to Github would only stop the ASF reporting schedule but does
> not address the issue of a viable future.
>
> Just my 2ct,
>
> Phil
>
>

Re: Tamaya's Future (was Re: Podling Tamaya Report Reminder - February 2020)

[Werner Keil]

I think this shows that best:
https://github.com/apache/incubator-tamaya/graphs/contributors

Werner




On Mon, Feb 10, 2020 at 10:06 PM Oliver B. Fischer 
wrote:

> And who is currently the most active contributer?
>
> Am 10.02.20 um 21:00 schrieb P. Ottlinger:
> > Hi *,
> >
> > Am 10.02.20 um 16:11 schrieb Oliver B. Fischer:
> >> who would describe themselves as an active committer?
> > Although I do not contribute that much code I'd consider myself an
> > active committer.
> >
> > @John: the release is officially out, we just did not announce it
> > properly due to the fact that we seem to lack a big community.
> >
> >
> > Cheers,
> > Phil
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
>

Re: Podling Tamaya Report Reminder - February 2020

[Werner Keil]

Hi,

Yes, OpenDDR and its interim attempt at Apache did graduate, but it had
quite a bit of momentum after the creators of WURFL defrauded the community
of their contributions and it is still relatively unique in that space at
least as an open alternative.

Tamaya never had that unique standpoint because many competing solutions
exist.

One alternative to preserve the codebase might be to simply put it back to
the Github organization Anatole created.

Another possible place that sounds more suitable for a  "Cloud Native" or
Microservice effort (sorry but except Big Data where it's quite strong
Apache just list in most of these other areas like IoT / Edge, Cloud Native
or Automotive) would be the CNCF.

While it has often half a dozen competing monitoring projects, the only
ones that are related to a Config store would be etcd or TiKV, but both
describe themselves as "NoSQL" storage, so they're not just for
configuration.

The CNCF has a more open and flexible "sandbox" phase for projects before
they even start incubating. Depending on the brand protection for incubator
projects (even Jakarta was made available to another community ;-) the name
Tamaya might be carried somewhere else. And at least right now there is no
dedicated configuration project covering what e.G. Archaius did.

It is still in an early phase but once the proposed Eclipse CN4J (Cloud
Native 4 Java) WG was formed, it might also be an alternative for a project
mostly for the JVM.

Werner

Julian Feinauer  schrieb am Mi., 22. Jan.
2020, 08:07:

> Hi all,
>
> thanks for putting this discussion up ( I also started a similar one on
> private which did not gain traction at all but I think its better to
> discuss it here, either way).
> For podlings there is no such thing as the attic so the natural way would
> be to move it over to Github and we could simplay grant full access to all
> current PPMC members.
>
> This would not change anything, I guess as we would still be able to make
> releases (under github not ASF Policy then) and keep on working but as the
> github infra is quite nice (with issues and wiki and all) I don’t think
> that it would suffer much.
>
> My honest opinion is that it will be extremely hard to get this podling to
> graduate anytime soon and that I currently don’t see that. So this could be
> a valid alternative.
>
> But ofc that’s just my opinion.
>
> Julian
>
> Am 19.01.20, 21:41 schrieb "Werner Keil" :
>
> Phil/all,
>
> Thanks for the discussion.
> I'm not sure, to what extent the ASF can really boost the project's
> popularity and adoption?
>
> There have been many uncertainties like the whole Config JSR issue,
> although that's now dead, but it still isn't completely sure, if
> MicroProfile Config would simply take its place or something inspired
> by it
> as well as other approaches like Oracle's Helidon?
> Most of it won't be effective until Jakarta EE 10, so another year
> since 9
> with its refactoring job isn't even scheduled, but it may come out
> around a
> year after Jakarta EE 8 (Sept '19) so with a possible annual release
> train
> like Eclipse had before this would be around Sep 2021 at the earliest.
>
> Until then the only thing would be to show TCK compatibility of MP
> Config
> and (not so different from Helidon) also provide some more powerful
> alternatives, including HOCON/Typesafe Config support.
>
> "Attic" isn't that where Tamaya would end up anyway, should it be
> discontinued?
> I can tell from the experience of OpenDDR - DeviceMap (which
> graduated) and
> back to its original brand, that this has not really hurt the project.
> On the contrary, while we did not track downloads much in 2017, the
> second
> half of 2018 alone (also did not watch it before) saw a massive boost
> in
> downloads of the "device data" artifact up to 500 or 600k in 2018.
> Last year it went back a bit, but it was still around 150k in 2019,
> roughly
> 10-12k per month on average (though it was not so evenly spread in
> reality)
> We could not get download stats from apache.org with the argument,
> that
> mirrors would not make that possible, so only the Maven repo downloads
> were
> available which never exceeded 200-250 in the peak days of Apache
> DeviceMap. Even in summer 2019 with a holiday gap OpenDDR data saw more
> downloads.
>
> As I have responsibilities for several Jakarta EE projects and the
> platform/Spec Committee, I also can't promise to contribute much.
>
> Beside Helidon which looks very healthy with steady contributions by
> Oracle
> and a few non-Oracle committers, Apache alone has

Re: Podling Tamaya Report Reminder - February 2020

[Werner Keil]

Phil/all,

Thanks for the discussion.
I'm not sure, to what extent the ASF can really boost the project's
popularity and adoption?

There have been many uncertainties like the whole Config JSR issue,
although that's now dead, but it still isn't completely sure, if
MicroProfile Config would simply take its place or something inspired by it
as well as other approaches like Oracle's Helidon?
Most of it won't be effective until Jakarta EE 10, so another year since 9
with its refactoring job isn't even scheduled, but it may come out around a
year after Jakarta EE 8 (Sept '19) so with a possible annual release train
like Eclipse had before this would be around Sep 2021 at the earliest.

Until then the only thing would be to show TCK compatibility of MP Config
and (not so different from Helidon) also provide some more powerful
alternatives, including HOCON/Typesafe Config support.

"Attic" isn't that where Tamaya would end up anyway, should it be
discontinued?
I can tell from the experience of OpenDDR - DeviceMap (which graduated) and
back to its original brand, that this has not really hurt the project.
On the contrary, while we did not track downloads much in 2017, the second
half of 2018 alone (also did not watch it before) saw a massive boost in
downloads of the "device data" artifact up to 500 or 600k in 2018.
Last year it went back a bit, but it was still around 150k in 2019, roughly
10-12k per month on average (though it was not so evenly spread in reality)
We could not get download stats from apache.org with the argument, that
mirrors would not make that possible, so only the Maven repo downloads were
available which never exceeded 200-250 in the peak days of Apache
DeviceMap. Even in summer 2019 with a holiday gap OpenDDR data saw more
downloads.

As I have responsibilities for several Jakarta EE projects and the
platform/Spec Committee, I also can't promise to contribute much.

Beside Helidon which looks very healthy with steady contributions by Oracle
and a few non-Oracle committers, Apache alone has 2 efforts:
https://github.com/apache/commons-configuration (also extremely active and
healthy)
https://github.com/apache/geronimo-config an independent implementation of
MP Config which seems practically abandoned for about a year, most likely
because of several other implementations including SmallRye, Thorntail,
Quarkus or Helidon.

So I really can't say, if there is enough momentum to keep it alive in its
current form. And simply putting it on GH, may not make much difference
either.

Which commercial clients are using Tamaya at the moment? And would they
suffer, if it was archived as is?

Looking at all the different MP implementations alone, not to mention their
much bigger competitors like Spring or Micronaut (all of them contain
configuration of their own) I am really skeptical, that it makes sense
unless a major increase in contributors and contributions occur.

Maybe it could be better for those with a vested interest in configuration
to help either the mentioned Apache projects or the others outside ASF.

WDYT?

Werner



On Sun, Jan 19, 2020 at 8:13 PM P. Ottlinger  wrote:

> Hi,
>
> Am 17.01.20 um 20:57 schrieb Anatole Tresch:
> > Honestly, I am opem to anything. Time actually is rare and I will not
> have
> > much in the next months either. We can think to move everything to GH and
> > continue there as time allows...
>
> The disadvantage of that would be we loose the umbrella of ASF with all
> its infrastructure and regulations /such as attic/.
>
> > There is not much innovation in this topic to ne expected either.
> >
> > Other opinions?
>
> If we graduate we need to establish some sort of momentum and definitely
> need more contributions.
>
> Anatole and me not having that much time in the coming weeks means
> roughly no changes at all 
>
> What do other contributors/list members think?
>
> Cheers,
> Phil
>

Re: [VOTE] Release of Apache Tamaya 0.4-incubating

[Werner Keil]

If it passed then it's fine.
There have been quite a few that already failed in the first step.

Julian Feinauer  schrieb am Do., 7. Nov.
2019, 13:36:

> Hi Werner,
>
> for podlings there are two votes.
> First the PPMC Vote (where you voted) and then if that passes an IPMC Vote.
> The second one is a formally binding vote for an Apache Release.
> A PPMC Vote alone is not (as its formally not an Apache PMC).
>
> Thus, two votes and the second one just finished : )
>
> Julian
>
> Am 07.11.19, 13:31 schrieb "Werner Keil" :
>
> I recall I voted on that already
>
> Anatole Tresch  schrieb am Do., 7. Nov. 2019,
> 11:53:
>
> > Great, thanks to all.
> >
> > I assume I will push out everything tomorrow or the WE. I will close
> the
> > vote in the next minutes...
> >
> > J Anatole
> >
> >
> > Am Do., 7. Nov. 2019 um 08:05 Uhr schrieb Julian Feinauer <
> > j.feina...@pragmaticminds.de>:
> >
> > >  and release to maven central via nexus : )
> > >
> > > Julian
> > >
> > > Am 07.11.19, 06:53 schrieb "P. Ottlinger" :
> > >
> > > Am 06.11.19 um 08:39 schrieb Julian Feinauer:
> > > > Hi, we just got the final 2 IPMC Votes, so you can finally
> finish
> > of
> > > the Release Anatole!
> > >
> > > @Julian,
> > > thanks :-)
> > >
> > > I did not change the board report  but this gives us the
> chance
> > to
> > > report something in the next cycle.
> > >
> > > @Anatole: I'm on a trade fair the coming days and will be
> unable to
> > > push
> > > the homepage changes; but the existing 0.4...-something branch
> should
> > > be
> > > the one to merge and push to get the new version out ;)
> > >
> > > Cheers,
> > > Phil
> > >
> > >
> > >
> >
> > --
> > *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: [VOTE] Release of Apache Tamaya 0.4-incubating

[Werner Keil]

I recall I voted on that already

Anatole Tresch  schrieb am Do., 7. Nov. 2019, 11:53:

> Great, thanks to all.
>
> I assume I will push out everything tomorrow or the WE. I will close the
> vote in the next minutes...
>
> J Anatole
>
>
> Am Do., 7. Nov. 2019 um 08:05 Uhr schrieb Julian Feinauer <
> j.feina...@pragmaticminds.de>:
>
> >  and release to maven central via nexus : )
> >
> > Julian
> >
> > Am 07.11.19, 06:53 schrieb "P. Ottlinger" :
> >
> > Am 06.11.19 um 08:39 schrieb Julian Feinauer:
> > > Hi, we just got the final 2 IPMC Votes, so you can finally finish
> of
> > the Release Anatole!
> >
> > @Julian,
> > thanks :-)
> >
> > I did not change the board report  but this gives us the chance
> to
> > report something in the next cycle.
> >
> > @Anatole: I'm on a trade fair the coming days and will be unable to
> > push
> > the homepage changes; but the existing 0.4...-something branch should
> > be
> > the one to merge and push to get the new version out ;)
> >
> > Cheers,
> > Phil
> >
> >
> >
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>

Re: ApacheCon in Berlin - anyone?

[Werner Keil]

I won't because I have a Jakarta EE talk at EclipseCon Europe and
another session about JSR 385 at Codemotion in the same week.

Werner



On Fri, Oct 4, 2019 at 8:58 PM Julian Feinauer 
wrote:

> Hi guys,
>
> I will be there, yes : )
>
> Julian
>
> Am 04.10.19, 17:20 schrieb "P. Ottlinger" :
>
> Hi guys,
>
> just reading Sally's weekly newsletter:
>
> 
> ApacheCon™ – the ASF's official global conference series, bringing
> Tomorrow's Technology Today since 1998
>  - *T-18 days* to ApacheCon Europe
> --TRACKS in Big Data, Cloud, Community, IoT, Machine Learning, Open
> Source Design, Servers, and more.
> --KEYNOTES by European Commission Director for Digital Business
> Solutions at the Directorate-General for Informatics (DG DIGIT) Thomas
> Gageik; Mastercard Executive Vice President for Global Cities Miguel A.
> Gamiño; and writer, political analyst, and activist Nanjala Nyabola.
> Plus special keynote panel with ASF Founders Lars Eilebrecht, Cliff
> Skolnick, and Dirk-Willem van Gulik.
> --SPECIAL EVENTS include BarCampApache, Hackathon, Movie Night, and
> more!
> --REGISTER TODAY and SAVE: EARLY REGISTRATION ends soon! Group
> rates
> available too  https://www.apachecon.com/
> 
>
> Is anyone from you in Berlin?
>
> I'm happy to meet you there in person!
>
> Cheers,
> Phil
>
>
>

Re: [VOTE] Release of Apache Tamaya 0.4-incubating-RC5

[Werner Keil]

+1
Werner

P. Ottlinger  schrieb am Mi., 2. Okt. 2019, 07:48:

> Am 25.09.19 um 14:41 schrieb Anatole Tresch:
> > The tag for this release candidate is available at [3] and [4]. It will
> be
> > renamed
> > once the vote passed.
> > Please take a look at the artifacts and vote!
>
> +1
>
> Works fine in my pet project.
>
> Cheers,
> Phil
>

Re: Podling Report Reminder - October 2019

[Werner Keil]

Did RC4 pass and was it deployed already?




On Mon, Sep 23, 2019 at 7:59 PM Anatole Tresch  wrote:

> Then lets go for rc5. It s not much work...
>
> Julian Feinauer  schrieb am Mo., 23. Sep.
> 2019, 19:54:
>
> > Hi Anatole,
> >
> > I think we should create a new vote for that, this is my gut feeling.
> > But we should discuss that openly.. what do you think, @Justin Mclean?
> > You brought that up.
> >
> > Julian
> >
> > Am 23.09.19, 19:17 schrieb "Anatole Tresch" :
> >
> > I think RC4 will be ready for the incubator vote soon. I will
> > add/update
> > the missing/outdated checksums by tomorrow latest and then close the
> > vote.
> >
> > J Anatole
> >
> > P. Ottlinger  schrieb am Mo., 23. Sep. 2019,
> > 18:51:
> >
> > > Am 23.09.19 um 12:46 schrieb Julian Feinauer:
> > > > Is anybody wlling to do this?
> > >
> > > I volunteer to compile the report :-)
> > >
> > > Sorry, have been offline due to hardware trouble and now my working
> > > environment is restored.
> > >
> > > Any particular issues to be reported except
> > > * new mentor Julian Feinauer, thanks :-)
> > > * release candidate RC4 is in the voting process
> > >
> > > Cheers,
> > > Phil
> > >
> >
> >
> >
>

Re: [VOTE] Release of Apache Tamaya 0.4-incubating-RC4

[Werner Keil]

Cool, then also

+1
from my side.

Hope it all works this time?

Werner



On Fri, Sep 13, 2019 at 1:06 PM Aaron Coburn  wrote:

> +1
>
> I verified the signatures and hashes for the api/core release as well as
> for the extensions.
> The code built correctly for me using Java 11 on a Mac:
>
> $ java -version
> java version "11.0.3" 2019-04-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
>
> The `mvn apache-rat:check` task looks good w/r/t license files
>
> And finally, I have a downstream project that uses the microprofile and cdi
> extensions, and that code all worked correctly when using the artifacts
> built from this release candidate.
>
> Thanks for pulling this together.
>
> Aaron
>
> On Thu, 12 Sep 2019 at 09:45, Anatole Tresch  wrote:
>
> > Hi,
> >
> > I was running the needed tasks to get the 0.4-incubating release of
> Tamaya
> > out.
> > The artifacts available via the Apache distribution repository [1] and
> > also via Apache's Nexus [2].
> >
> > The tag for this release candidate is available at [3] and will be
> renamed
> > once the vote passed.
> > Please take a look at the artifacts and vote!
> >
> > Please note:
> > This vote is a "majority approval" with a minimum of three +1 votes (see
> > [4]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> and
> > why ...
> > 
> >
> > Thanks,
> > Anatole Tresch
> >
> > [1]
> > https://dist.apache.org/repos/dist/dev/incubator/tamaya/0.4-incubating/
> >
> > [2]
> > https://repository.apache.org/content/repositories/orgapachetamaya-1039
> > [3]
> >
> >
> https://gitbox.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=f9cecfd65b3f5241651813be12b46b8d0cef1472
> >
> > [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
> >
> >
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com  *
> > *Twitter:  @atsticks, @tamayaconf*
> >
>

Re: [VOTE] Release of Apache Tamaya 0.4-incubating

[Werner Keil]

Could you point us/Anatole to how it can be addressed?

Thanks,

Werner




On Mon, Aug 26, 2019 at 6:08 PM Aaron Coburn  wrote:

> The staging repository should be exactly the same as the eventual released
> artifacts. You can see in the POM file for the microprofile artifact that
> it depends on a SNAPSHOT API:
>
> https://repository.apache.org/content/repositories/orgapachetamaya-1036/org/apache/tamaya/ext/tamaya-microprofile/0.4-incubating/tamaya-microprofile-0.4-incubating.pom
>
> If released as-is, the microprofile artifact will not work properly. (The
> same applies to the -sandbox items)
>
>
>
>
> On Mon, 26 Aug 2019 at 11:43, Werner Keil  wrote:
>
> > Wouldn't it be possible to change from snapshot only once 0.4 is
> released,
> > or should it work without Snapshot in staging?
> >
> > Aaron Coburn  schrieb am Mo., 26. Aug. 2019,
> > 17:37:
> >
> > > -1 (non-binding)
> > >
> > > The microprofile extension depends on the tamaya-api
> > > 0.4-incubating-SNAPSHOT artifact, which will cause problems when trying
> > to
> > > use that (and that is the artifact I am most interested in using)
> > >
> > >
> > >
> >
> https://github.com/apache/incubator-tamaya-extensions/blob/vote-0.4-incubating-01/modules/microprofile/pom.xml#L39
> > >
> > > In the sandbox modules, it appears that most (all?) of the modules
> depend
> > > on SNAPSHOT artifacts from tamaya-api and various -extension artifacts:
> > >
> > >
> >
> https://github.com/apache/incubator-tamaya-sandbox/blob/vote-0.4-incubating-01/pom.xml#L43
> > >
> > > Less significant: examples 05 and 06 in the extension repo also depend
> on
> > > snapshot artifacts.
> > >
> > > Otherwise, the code builds and tests correctly.
> > >
> > > Aaron
> > >
> > >
> > >
> > > On Sun, 25 Aug 2019 at 11:42, Anatole Tresch 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I was running the needed tasks to get the 0.4-incubating release of
> > > Tamaya
> > > > out.
> > > > The artifacts available via the Apache's Nexus [1].
> > > > The tag for this release candidate is available at [2] and will be
> > > renamed
> > > > once the vote passed.
> > > >
> > > > Please take a look at the artifacts and vote!
> > > >
> > > > Please note: This vote is a "majority approval" with a minimum of
> three
> > > +1
> > > > votes (see [3]).
> > > >
> > > > 
> > > > [ ] +1 for community members who have reviewed the bits
> > > > [ ] +0
> > > > [ ] -1 for fatal flaws that should cause these bits not to be
> released,
> > > and
> > > > why ...
> > > > 
> > > >
> > > > Thanks,
> > > > Anatole Tresch
> > > >
> > > > [1]
> > > >
> > https://repository.apache.org/content/repositories/orgapachetamaya-1036/
> > > >
> > > > [2]
> > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=d2d60786e3e72a2bb16e14e1b195f7b2487a33eb
> > > >
> > > > [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
> > > >
> > > >
> > > > --
> > > > *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: [VOTE] Release of Apache Tamaya 0.4-incubating

[Werner Keil]

Wouldn't it be possible to change from snapshot only once 0.4 is released,
or should it work without Snapshot in staging?

Aaron Coburn  schrieb am Mo., 26. Aug. 2019, 17:37:

> -1 (non-binding)
>
> The microprofile extension depends on the tamaya-api
> 0.4-incubating-SNAPSHOT artifact, which will cause problems when trying to
> use that (and that is the artifact I am most interested in using)
>
>
> https://github.com/apache/incubator-tamaya-extensions/blob/vote-0.4-incubating-01/modules/microprofile/pom.xml#L39
>
> In the sandbox modules, it appears that most (all?) of the modules depend
> on SNAPSHOT artifacts from tamaya-api and various -extension artifacts:
>
> https://github.com/apache/incubator-tamaya-sandbox/blob/vote-0.4-incubating-01/pom.xml#L43
>
> Less significant: examples 05 and 06 in the extension repo also depend on
> snapshot artifacts.
>
> Otherwise, the code builds and tests correctly.
>
> Aaron
>
>
>
> On Sun, 25 Aug 2019 at 11:42, Anatole Tresch  wrote:
>
> > Hi,
> >
> > I was running the needed tasks to get the 0.4-incubating release of
> Tamaya
> > out.
> > The artifacts available via the Apache's Nexus [1].
> > The tag for this release candidate is available at [2] and will be
> renamed
> > once the vote passed.
> >
> > Please take a look at the artifacts and vote!
> >
> > Please note: This vote is a "majority approval" with a minimum of three
> +1
> > votes (see [3]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> and
> > why ...
> > 
> >
> > Thanks,
> > Anatole Tresch
> >
> > [1]
> > https://repository.apache.org/content/repositories/orgapachetamaya-1036/
> >
> > [2]
> >
> >
> https://gitbox.apache.org/repos/asf?p=incubator-tamaya.git;a=commit;h=d2d60786e3e72a2bb16e14e1b195f7b2487a33eb
> >
> > [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com  *
> > *Twitter:  @atsticks, @tamayaconf*
> >
>

Re: FW: [OFFER] Offer to Mentor one or two podlings

[Werner Keil]

Julian,

Thanks for your interest in mentioning.
I also haven't had a chance to help with too many parts of Tamaya except
for a bit of HOCOM aspects, as I have duties in other Open Source
communities like the JCP or Eclipse (Jakarta EE)

One major difference is, that Tamaya adds more support for distributed
configuration like Spring Cloud or Netflix Archaius. Which is no longer
actively maintained but it used Commons Config under the hood.
Something Tamaya also could do in a similar way, there could even be a
Sandbox effort for it.
As of now I don't think this cloud configuration with multiple distributed
sources is in scope for Commons Config. And as long as this does not change
it makes Tamaya an effort worth persuing as long as enough people can help.

Regards,
Werner

Julian Feinauer  schrieb am Mi., 21. Aug.
2019, 16:24:

> Hi all,
>
> I came here by Johns mail and just had a Quick look over the homepage.
> The project looks very interesting and useful.
> But one question I have is, is there a clear differentiation between
> tamaya and other frameworks like Apache Commons Configuration (or others).
>
> Thanks already for the response!
> Julian
>
> Am 20.08.19, 17:42 schrieb "John D.Ament" :
>
> Julian,
>
> Apache Tamaya could use help.  My activity has been reduced pretty
> heavily as of late.
>
> John
>
> On 2019/08/13 06:21:54, Julian Feinauer 
> wrote:
> > Hi,
> >
> > this goes to the IPMC as well as to podlings watching this list.
> > I just recently became IPMC member and am currently pretty active in
> the IoTDB Project as “informal mentor” (started there before becoming IPMC
> member) together with 3 other pretty active mentors.
> > As I received a lot of help from mentors and learned a lot about the
> Apache Way since I joined incubating projects, I think its time now to give
> something back. I could join one or two other podlings as Mentor if I am
> needed.
> >
> > I gained a reasonable amount of “podling” experience hands-on during
> the last 2 years after joining the PLC4X project and moving from release
> 0.1 to TLP and am active in other Podlings.
> > My main interest is in the IoT, Big Data and analytics area (I’m
> active in PLC4X, Edgent, IoTDB and sometimes in Calcite) and mostly on the
> JVM. So this is the area where I could help most, I guess.
> >
> > So if someone has an idea where I can help, feel free to contact me!
> >
> > Julian
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>

Re: Starting with the preparation of the next release of Tamaya

[Werner Keil]

+1

Werner



On Mon, Aug 19, 2019 at 10:13 PM William Lieurance <
william.lieura...@namikoda.com> wrote:

> Please do. Let me know if I can be of any help.
>
> Sent from a tiny keyboard
>
> 
> From: Anatole Tresch 
> Sent: Monday, August 19, 2019 5:44:37 AM
> To: dev@tamaya.incubator.apache.org 
> Subject: Starting with the preparation of the next release of Tamaya
>
> Dear all,
>
> If there are no objections, I'll start with the first steps for
> the next release of Apache Tamaya Version 0.4-incubating.
> It will start with the release procedure within this week.
>
> Best regards,
> Anatole
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>

Re: release it!

[Werner Keil]

It would be a good idea to deprecate the JSR support and remove it in a
future release.

Werner



On Wed, Jul 17, 2019 at 8:24 AM Anatole Tresch  wrote:

> OK, let's check how the release documentation looks like (AFAIK Oli did one
> the last time). If this works, things should be relatively easy. Since we
> do not build a binary release, main tasks are pre-releasing (building,
> testing, tagging) and go for the release votes ones things are in place.
> The homepage can be updated in a second step.
>
> Am Mi., 17. Juli 2019 um 00:21 Uhr schrieb William Lieurance <
> william.lieura...@namikoda.com>:
>
> > I'll certainly +1 a release now and also am in favor of more frequent
> > releases in the future.
> >
> > Sent from a tiny keyboard
> >
> > 
> > From: P. Ottlinger 
> > Sent: Tuesday, July 16, 2019 5:17:48 PM
> > To: dev@tamaya.incubator.apache.org
> > Subject: Re: release it!
> >
> > Am 17.07.19 um 00:16 schrieb Werner Keil:
> > > The JSR will never be out, it was withdrawn in favor of either
> > MicroProfile
> > > Config, a future Jakarta spec or both.
> > > the Jakarta spec is not there but keeping the old JSR in there would
> > cause
> > > more confusion, in a sandbox module I guess it is at people's own risk.
> >
> >
> > thanks for the explanation - why don't we release it with 0.4 and remove
> > it with 0.5?
> >
> > This would mean a higher release frequency which could help us graduate
> > as a TLP ;)
> >
> > Cheers,
> > Phil
> >
>
>
> --
> *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: release it!

[Werner Keil]

Phil,

The JSR will never be out, it was withdrawn in favor of either MicroProfile
Config, a future Jakarta spec or both.
the Jakarta spec is not there but keeping the old JSR in there would cause
more confusion, in a sandbox module I guess it is at people's own risk.

Werner



On Wed, Jul 17, 2019 at 12:38 AM P. Ottlinger  wrote:

> Am 16.07.19 um 16:42 schrieb Anatole Tresch:
> > the jsr382 module is in the sandbox and can be deleted or just removed
> from
> > the build. Any new abstractions from the jsr have been moved to the
> > microprofile api, but were not yet released, so the code written there
> will
> > be of great use once the next mp release is ready...
>
> I'd release it as it is . in case the new JSR is out, we might
> remove it then.
>
> To my mind there's so much change in the current version to rectify a
> release.
>
> I'm still not really able to do the release  any other volunteer: go
> ahead.
>
> I can help a bit if there are questions concerning the homepage and
> stuff like that ...
>
> Cheers,
> Phil
>

Re: release it!

[Werner Keil]

I'm not sure about the part that implemented JSR 182. Was that official or
in the sandbox modules?

I would deprecate those in a new release because the JSR stopped.

At the moment Microprofile Config is an alternative. A Jakarta spec is
planned but not sure when it will start.

Werner

Aaron Coburn  schrieb am Di., 16. Juli 2019, 15:03:

> Yes, let's definitely cut a release. +1
>
> Cheers,
> Aaron
>
>
>
> On Tue, 16 Jul 2019 at 05:16, Anatole Tresch  wrote:
>
> > Hi Guys
> >
> > is there anything that speaks against building a new release? If no, we
> > should build one.
> >
> > J Anatole
> >
>

Re: Returning to Tamaya

[Werner Keil]

Because we (Anatole as well) already have DWX in June, I can't say for next
month, unless we did get a mandatory workshop in Berlin with the partner
company.

Werner



On Mon, May 27, 2019 at 9:35 PM Anatole Tresch  wrote:

> ok, I will check my calendar, roughly mid of June could work...We-Fr
> matches best...
>
> P. Ottlinger  schrieb am Mo., 27. Mai 2019, 21:01:
>
> > Hi,
> >
> > I could provide a location for a not too big meetup 
> > just let me know, Oliver+Werner :-)
> >
> > Cheers,
> > Phil
> >
> > Am 27.05.19 um 19:49 schrieb Werner Keil:
> > > If you can at a shorter notice, it would be great. I am not sure when
> we
> > > have to be in Berlin, it might be between July and August once, but
> that
> > is
> > > probably not a good time during the holidays.樂
> > >
> > > Werner
> > >
> > >
> > >
> > > On Mon, May 27, 2019 at 7:29 PM Anatole Tresch 
> > wrote:
> > >
> > >> I can do so yes... also did that in earlier days
> >
>

Re: Returning to Tamaya

[Werner Keil]

If you can at a shorter notice, it would be great. I am not sure when we
have to be in Berlin, it might be between July and August once, but that is
probably not a good time during the holidays.樂

Werner



On Mon, May 27, 2019 at 7:29 PM Anatole Tresch  wrote:

> I can do so yes... also did that in earlier days
>
> Oliver B. Fischer  schrieb am So., 26. Mai 2019,
> 22:31:
>
> > Would you come to Berlin for a talk at our local JUG?
> >
> > Am 26.05.19 um 22:09 schrieb Anatole Tresch:
> > > sorry, we in general are more difficult as well foe me. 1st of June
> does
> > > not work at all (children time)...
> > >
> > > How about meeting at some Hackergarden or organizing a JUG Talk?
> > >
> > > J Anatole
> > >
> > >
> > >
> > > Oliver B. Fischer  schrieb am Sa., 25. Mai
> > 2019,
> > > 12:12:
> > >
> > >> Ping
> > >>
> > >> Am 17.05.19 um 14:42 schrieb Oliver B. Fischer:
> > >>> Would be the 1st of June fine for us?
> > >>>
> > >>> Am 15.05.19 um 11:20 schrieb Oliver B. Fischer:
> > >> --
> > >> N Oliver B. Fischer
> > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >> P +49 30 44793251
> > >> M +49 178 7903538
> > >> E o.b.fisc...@swe-blog.net
> > >> S oliver.b.fischer
> > >> J oliver.b.fisc...@jabber.org
> > >> X http://xing.to/obf
> > >>
> > >>
> > >>
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fisc...@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fisc...@jabber.org
> > X http://xing.to/obf
> >
> >
> >
>

Re: Returning to Tamaya

[Werner Keil]

I was there a little while ago when the JCP EC met in Berlin.
Which subject would you have in mind, Tamaya or something else?

I could but not sure, if it works before the summer or afterward.
The current client and project have partners to meet in Berlin, so it would
be great if that could work alongside one of those meetings we expect in
Berlin.

Werner




On Sun, May 26, 2019 at 10:32 PM Oliver B. Fischer 
wrote:

> Would you come to Berlin for a talk at our local JUG?
>
> Am 26.05.19 um 22:09 schrieb Anatole Tresch:
> > sorry, we in general are more difficult as well foe me. 1st of June does
> > not work at all (children time)...
> >
> > How about meeting at some Hackergarden or organizing a JUG Talk?
> >
> > J Anatole
> >
> >
> >
> > Oliver B. Fischer  schrieb am Sa., 25. Mai
> 2019,
> > 12:12:
> >
> >> Ping
> >>
> >> Am 17.05.19 um 14:42 schrieb Oliver B. Fischer:
> >>> Would be the 1st of June fine for us?
> >>>
> >>> Am 15.05.19 um 11:20 schrieb Oliver B. Fischer:
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E o.b.fisc...@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fisc...@jabber.org
> >> X http://xing.to/obf
> >>
> >>
> >>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
>

Re: Returning to Tamaya

[Werner Keil]

For me neither, I have an Adopt-a-JSR session with JUG Utrecht.

Werner


On Sun, May 26, 2019 at 10:10 PM Anatole Tresch  wrote:

> sorry, we in general are more difficult as well foe me. 1st of June does
> not work at all (children time)...
>
> How about meeting at some Hackergarden or organizing a JUG Talk?
>
> J Anatole
>
>
>
> Oliver B. Fischer  schrieb am Sa., 25. Mai 2019,
> 12:12:
>
> > Ping
> >
> > Am 17.05.19 um 14:42 schrieb Oliver B. Fischer:
> > > Would be the 1st of June fine for us?
> > >
> > > Am 15.05.19 um 11:20 schrieb Oliver B. Fischer:
> > >>
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fisc...@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fisc...@jabber.org
> > X http://xing.to/obf
> >
> >
> >
>

Re: Returning to Tamaya

[Werner Keil]

I may be traveling to a Dutch Meetup then.

Oliver B. Fischer  schrieb am Fr., 17. Mai 2019,
14:43:

> Would be the 1st of June fine for us?
>
> Am 15.05.19 um 11:20 schrieb Oliver B. Fischer:
> > Hi,
> >
> > I can only offer an appointment for the 1th or 2nd of June... ?
> >
> > Best,
> >
> > Oliver
> >
> > Am 13.05.19 um 22:11 schrieb William Lieurance:
> >> 5/27 works. It's a holiday here in the states. :-)
> >>
> >> Sent from a tiny keyboard
> >>
> >> 
> >> From: Aaron Coburn 
> >> Sent: Monday, May 13, 2019 3:07:09 PM
> >> To: dev@tamaya.incubator.apache.org
> >> Subject: Re: Returning to Tamaya
> >>
> >> I would be interested in joining. 5/27 at the time you suggested works
> for
> >> me.
> >>
> >> Cheers, Aaron
> >>
> >> On Mon, 13 May 2019 at 15:59, P. Ottlinger 
> wrote:
> >>
> >>> Am 13.05.19 um 21:51 schrieb Oliver B. Fischer:
>  Monday and Tuesday I will be in St. Petersburg on vacation. ;-)
> >>> what about:
> >>>
> >>> 2019-05-27 8pm Berlin time?
> >>>
> >>> Cheers,
> >>> Phil
> >>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
>

Re: Returning to Tamaya

[Werner Keil]

Hi Oliver,

That's great news.
I may be in Berlin at some point for a meeting with clients in the current
project.

Any chance for a Tamaya proposal to Apachecon Berlin anyone or is it too
short notice?

Werner

Anatole Tresch  schrieb am Mo., 13. Mai 2019, 08:37:

> Hi Oliver
>
> thats awesome news. Probably we can also do a hangout...?
>
> J Anatole
>
> Oliver B. Fischer  schrieb am Mo., 13. Mai 2019,
> 08:23:
>
> > Dear all,
> >
> > after quite a while of absence I would like to return to our project and
> > to contribute again.
> >
> > Maybe I and Philipp can meet in Berlin in the next two weeks to talk
> about
> > the current status of Tamaya and pending work.
> >
> > Best,
> >
> > Oliver
> >
> >
> >
>

Re: Short Update

[Werner Keil]

Anatole,

Thanks for the update. Which modules deal with HOCON support? I'd be happy
to look at those since I contributed to some of the extension/incubation
modules around HOCON and supporting units in configuration like Typesafe
Config does.

Regards,

Werner


On Sun, May 12, 2019 at 6:38 PM Anatole Tresch  wrote:

> Hi Guys
>
> I just wanted to give a short update on my work. I am currently upgrading
> things so we can successfully implemen the Microprofile 1.3 TCK. As of now
> only 3 tests still fail, so hopefully in a few days this is ready. I
> propose we should then build a release once we think this is works.
>
> Actually I also was playing around with the metaconfig feature, since in
> helidon.io this has been implemented as well. Therefore I added format
> support for HOCON as well and based the metaconfig feature on the new
> property API making it multiformat capable. As a result HOCON and HJSON
> support could be easily added to the extensions catalogue, since they are
> structurally identical with the existing JSON support.
>
> Stay tuned.
>
> J Anatole
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>

Re: another approach to configuration: project helidon/oracle podcast

[Werner Keil]

Another reason why on behalf of the Jakarta EE Spec committee I try to help
the JSR EG and Spec Leads out of the hole they dug themselves into and see
how it could become a Jakarta EE Spec instead.

IMO the MP API which already used by some of those products could be be
largely used and maybe just Spec documents or TCK from the JSR where they
exist.

Anybody proposed a talk for Berlin BTW.?

Werner


Anatole Tresch  schrieb am Mo., 22. Apr. 2019, 02:14:

> Hi all
>
> looks intetesting indeed. The main config API is something similar to the
> jsr api, but looks much more clean and elegant to me. Something we can add
> or support as well (will have a deeper look into helidon).
> very interesting is also the metaconfiguration feature, since I also
> started a similar module in the sandbox.
> btw, yes, Dmitry is the guy from Oracle
>
> J, Anatole
>
>
>
> P. Ottlinger  schrieb am So., 21. Apr. 2019, 23:39:
>
> > Hi,
> >
> > just tuning in into an Oracle podcast about project Helidon - yet
> > another/a different approach to configuration in Java Microservices/JEE:
> > https://helidon.io/docs/latest/#/config/01_introduction
> >
> > Just to get some inspiration ;)
> >
> > Helidon doesn't have a Tamaya integration yet, but seems to rely on
> > Microprofile as well:
> > https://helidon.io/docs/latest/#/microprofile/02_server-configuration
> >
> > @Anatole: hasn't Dmitry Kornilov been the guy that was involved from
> > Oracle when starting a JSR was an ongoing discussion?
> >
> > Thanks,
> > Phil
> >
> > PS: That's the podcast episode:
> > https://blogs.oracle.com/developers/podcast-on-the-highway-to-helidon
> >
>

Re: Podling report due today

[Werner Keil]

The underlying standardization effort is stalled and so far has not made up
their minds whether to continue the inactive JSR 382 (it is artificially
kept "active", in reality it has not released an EDR since October 2017:
https://jcp.org/en/jsr/detail?id=382
Tamaya implements both that JSR and the somewhat more active non-standard
MicroProfile Config.

When it comes to that, I'm not sure, if it's still up to date, but as for
the standard, there are other problems these standardization efforts have
to solve before it is safe to implement anything.




On Sun, Mar 10, 2019 at 11:56 PM John D. Ament 
wrote:

> I'd strongly recommend that the podling seek more mentors, and perhaps
> figure out if they are actually going to be a viable Apache project.
> Tamaya has been incubating 2014-November, and hasn't had a release in 2
> years, the most recent committer change came a very long time after the
> last change.  This is really not expected for a podling.
>
> I plan to add these comments to the report.
>
> John
>
> On Sun, Mar 10, 2019 at 4:32 PM Justin Mclean  wrote:
>
> > Hi,
> >
> > > I just saw that none of our mentors have signed off the report at
> > > https://wiki.apache.org/incubator/March2019
> > >
> > > Can we do something about that?!
> >
> > Just remind them as you have done so and perhaps ask for another mentor
> on
> > gerneral@
> >
> > Thanks,
> > Justin
>

Yet another Microframework

[Werner Keil]

Hi,

I heard about Apache Juneau a few days ago by an article on Heise.
https://juneau.apache.org

It seems John is involved although the only serious committer is just one
person with Millions of  LOC over the past 2 years. Shows, even a
relatively small project with just half a dozen committers may graduate
from the incubator if one or two contribute such large amounts;-)

It mentions quite a few features not so different from Eclipse
MicroProfile, but does not seem to use any of it.
It does however use Spring Boot among other containers like Jetty.

The config module seems quite familiar to the HierarchicalConfiguration
feature of Apache Commons Config, although it also does not look like a
dependency.
It looks like something totally independent, which at most could benefit
from Jakarta EE some day, otherwise it's more of a MicroProfile competitor.

Werner

Re: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Werner Keil]

+1 for moving, seems the standard way for all repositories, so better
migrate.

Werner



On Mon, Dec 10, 2018 at 8:59 PM P. Ottlinger  wrote:

> Am 08.12.18 um 20:36 schrieb P. Ottlinger:
> > Any objections or can I file an issue to move us over to the new system?
>
> Filed
> https://issues.apache.org/jira/browse/INFRA-17389
> to trigger the migration.
>
> Let's see how things evolve and how powerful the github integration will
> become :-)
>
> Phil
>

Archaius

[Werner Keil]

Guys,

It may not apply to Archaius at this point, but in a MicroProfile lab Emily
is doing here at Java2Days she mentioned, Netflix will no longer contribute
to Hystrix. A rather crucial piece for circuit breakers for the Spring
stack.

If Netflix also pulled the plug on Archaius, this shows, why it is a good
idea to continue with Tamaya because next to Archaius there few OpenSource
solutions for distributed Configuration in the Cloud (maybe Spring Config
but it only works with the Spring stack) so whether based on MicroProfile
Config, JSR 382 or a potential Jakarta.Config, having an Open Source
project that is not dominated by a single vendor and committer seems like a
good idea.

Werner

Re: RFC: Draft for report - will submit at 2018-11-06

[Werner Keil]

William,

Great news, that allows you to also help other JSRs, e.g. 381 which has
some ties to Apache projects like MXNet or SystemML.
Of course you could join JSR 382 as a contributor:
https://jcp.org/en/jsr/detail?id=382. Use the "I would like to join this
JSR" link.

I really can't tell what they gonna do with it, there should have been a
Renewal Ballot but it may at least have to wait till after the current JCP
EC elections.
Hope to learn more in a week when I meet both Emily (one of the Spec Leads)
and Otavio as well as Ondro from Payara which does not contribute to JSRs
(at least not as a company) but does quite a bit at Eclipse through Jakarta
EE or MicroProfile. I also initiated a Jakarta EE panel discussion at
Java2Days and topics like JCP vs. Jakarta EE (there are still a few JSRs
like CDI or Bean Validation)

Werner




On Fri, Nov 16, 2018 at 11:31 PM William Lieurance <
william.lieura...@namikoda.com> wrote:

> Hi Werner,
>
> I've signed up for the JCP as an Associate member.   Politics don't really
> bother me. ;-)  How would you recommend someone like me get involved in the
> Jakarta EE environment as things are shifting towards that direction?
>
> --William
> ____
> From: Werner Keil 
> Sent: Wednesday, November 7, 2018 12:12 PM
> To: dev@tamaya.incubator.apache.org
> Subject: Re: RFC: Draft for report - will submit at 2018-11-06
>
> William,
>
> Thanks for the reply. Are you a member of the JCP as well? Either Associate
> (contributors can pretty much help with almost everything, too) or Full JCP
> Member?
>
> I'm afraid there's a lot of politics, I just joined the regular Jakarta EE
> Spec Committee call and while I won't disclose more than the minutes should
> document anyway, there is a looming worry, that not only the GroupId has to
> change but also other dependencies including existing JSRs like CDI, etc.
> that use the "javax" package namespace or quote the term "Java" could be at
> risk. That certainly speaks a great bit against JSR 382 which uses the
> "javax" namespace and could mean, Eclipse Foundation would rather have to
> start from scratch or simply derive what was done at MicroProfile Config
> into a new Jakarta.config spec. I cannot say which way it'll happen,  but
> there are a lot of things discussed and lawyers promised stuff (I already
> know that kind of "Waiting for Godot" while I was still in the JCP EC and
> Java EE 8 was in a standstill) which nobody dares to make binding decisions
> before they delivered on those promises.
>
> Werner
>
>
>
>
> On Wed, Nov 7, 2018 at 6:51 PM William Lieurance <
> william.lieura...@namikoda.com> wrote:
>
> > *blush* I'm just happy to be able to help.
> >
> > In truth, I think once the substantial api/spi changes that Anatole has
> > mentioned for jsr382 (and I think I saw on a branch accidentally) go in,
> > the biggest thing we are missing is breadth of documentation and even
> more
> > examples. Our current answer of "Go look at the tests" to find how to use
> > tamaya is ok for now but is probably a stumbling block for developers
> > looking for the easiest path to onboard themselves.
> >
> > I'm super interested in helping out with getting jsr382 across the finish
> > line to unblock that effort and then start churning out examples for all
> > the different kinds of uses that tamaya has. I think that's also the way
> to
> > start getting more people using and then ultimately involved with tamaya.
> >
> > --William
> >
> > Sent from a tiny keyboard
> >
> > 
> > From: Werner Keil 
> > Sent: Wednesday, November 7, 2018 9:43:13 AM
> > To: dev@tamaya.incubator.apache.org
> > Subject: Re: RFC: Draft for report - will submit at 2018-11-06
> >
> > Btw both the contribution activity in JSR 382 (see before) and
> MicroProfile
> > Config:
> https://github.com/eclipse/microprofile-config/graphs/contributors
> > have massively decreased since a peak about a year ago.
> > And there are just 2 who contributed more than 5k LOC, 2 (including John)
> > with up to 1.5k LOC and the rests is irrelevant with sometimes only a
> > character or two contributed.
> >
> > Compared to both of them Tamaya looks quite good:
> > https://github.com/apache/incubator-tamaya/graphs/contributors
> > 2 contributed over 20k LOC, 1 over 5k and 2 others over 1.5k over the
> > history of the project.
> >
> > I did not realize how much William has done, so why haven't we voted on
> his
> > committer role already?
> >
> > Werner
> >
> >
> &

Re: Work pushed

[Werner Keil]

Hi,

Was this why most builds broke for a while?

Thanks and Regards,

Werner



On Sun, Nov 18, 2018 at 10:51 PM Anatole Tresch  wrote:

> Hi Guys
>
> I pushed everything now from my machine. All builds worked fine, keeping
> fingers crossed they will do also on the build servers. From a functional
> perspective I think this is basically the things that should be ready for
> the next release. Before I would be incredibly thankful for everybody
> hacing a look and probably give feedback. I try to summarize the most
> important points:
>
>
>- Using Java 8 features on the API the current *ConfigurationProvider *can
>be deprecated in favour of static methods on the *Configuration *interface.
>This reduces the API size overall.
>- For having control about backward compatibility I added revapi
>reports to all core and extension modules, they will be generated under
>target/site during the normal build and can be opened using a browser.
>There you can easily see that especially in the SPI area some changes are
>definitively breaking changes, whereas the API is still basically stable,
>with some deprecations...
>- *ConfigQuery *and *ConfigOperator *were deprecated in favour of
>*UnaryOperator* and *Function.* The
>old artifacts are still in place for backward compatibility.
>- Configuration and also all other parts/modules can now be accessed
>passing a specific target classloader. This change actually makes really
>sense, but required a few incompatible changes, especially in the
>extensions part. The core API has been extended only. At it's core the
>*ServiceContext*, which actually manages all components loaded in a
>runtime context is now *Classloader *aware. Each configuration
>instance has a reference to it's own *ServiceContext*. Components that
>require access to the current *ClassLoader *can simply implement the 
> *ClassloaderAware
>*interface (added to the core SPI). When loaded by the *ServiceContext
>*the current target classloader gets passed.
>- For consistent configuration access a similar enum like the config
>JSR has been added, where a *PropertySource *can declare if it
>supports consistent access, os is even immutable. Similaly a String 
> *getVersion()
>*method has been added, where a property source can return it's
>version identifiers. This allows a configuration to ensure, when consistent
>access is supported, that the values accessed are consistent, when the
>versions before and after reading the values are the same.
>- The JSR provides a snapshot feature, which in combination with the
>atomic access makes sense as well. In Tamaya in the event module a similar
>feature already was implemented. I moved this feature into the core API and
>the implementation moved into the support module. The existing "
>*FrozenConfiguration/FrozenPropertySource*" classes have been
>deprecated and all accessing code has been adapted.
>- As already mentioned the internal representation structures (
>*PropertyValue*) were extended by Map-liked data (*ObjectValue*) and
>array like data (*ListValue*). This enables also more complex mappings
>and type conversions from typical file formats to be quite easily
>realizable.
>- The homepage was extended by a simple logo, which models the "in the
>middle" meaning of the indian name Tamaya. I think it's nice and simple, so
>my proposal is to go with it for now (see also below).
>- Beside the logo I also added a complete new entry page with some
>nice (I think) advertising intros of Tamaya. To give feedback, best would
>be to check the site master repo out and build the site with jbake and view
>it on your local browser. This site also includes the overall
>documentation, which also has been adapted to the changes done. So it would
>make sense to publish the new site along the new version, once it's ready.
>- The JSR module implements the latest state of the JSR (one week old).
>- I did not update the Microprofile implementation (AFAIK it still
>implements MP 1.1 Config API).
>- Beside the collections module I also simplified the modules for
>consul, Hazelcast and etd support. So I think we can release them as
>extensions as well (they are ultra small).
>
> There will be some places (snapshots, ObjectValue, ListValue for example),
> where additional test code would be required, but overall things should be
> working quite fine and if you agree, we should be basically ready to
> release now. Of course, feedback or improvements are very welcome!
>
> Have a nice time. I hope you enjoy the new stuff ;-)
> Anatole
>
> PS: As mentioned, here the logo proposal:
>
> [image: tamaya.png]
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com 

Re: RFC: Draft for report - will submit at 2018-11-06

[Werner Keil]

We discussed this a while ago that the mentors have not been available in
most cases.

Werner

Am Do., 8. Nov. 2018, 07:15 hat Justin Mclean 
geschrieben:

> Hi,
>
> Would be good if you also answered this question in the report:
> > Have your mentors been helpful and responsive or are things falling
> > through the cracks? In the latter case, please list any open issues
> > that need to be addressed.
>
> Thanks,
> Justin
>

Re: RFC: Draft for report - will submit at 2018-11-06

[Werner Keil]

William,

Thanks for the reply. Are you a member of the JCP as well? Either Associate
(contributors can pretty much help with almost everything, too) or Full JCP
Member?

I'm afraid there's a lot of politics, I just joined the regular Jakarta EE
Spec Committee call and while I won't disclose more than the minutes should
document anyway, there is a looming worry, that not only the GroupId has to
change but also other dependencies including existing JSRs like CDI, etc.
that use the "javax" package namespace or quote the term "Java" could be at
risk. That certainly speaks a great bit against JSR 382 which uses the
"javax" namespace and could mean, Eclipse Foundation would rather have to
start from scratch or simply derive what was done at MicroProfile Config
into a new Jakarta.config spec. I cannot say which way it'll happen,  but
there are a lot of things discussed and lawyers promised stuff (I already
know that kind of "Waiting for Godot" while I was still in the JCP EC and
Java EE 8 was in a standstill) which nobody dares to make binding decisions
before they delivered on those promises.

Werner




On Wed, Nov 7, 2018 at 6:51 PM William Lieurance <
william.lieura...@namikoda.com> wrote:

> *blush* I'm just happy to be able to help.
>
> In truth, I think once the substantial api/spi changes that Anatole has
> mentioned for jsr382 (and I think I saw on a branch accidentally) go in,
> the biggest thing we are missing is breadth of documentation and even more
> examples. Our current answer of "Go look at the tests" to find how to use
> tamaya is ok for now but is probably a stumbling block for developers
> looking for the easiest path to onboard themselves.
>
> I'm super interested in helping out with getting jsr382 across the finish
> line to unblock that effort and then start churning out examples for all
> the different kinds of uses that tamaya has. I think that's also the way to
> start getting more people using and then ultimately involved with tamaya.
>
> --William
>
> Sent from a tiny keyboard
>
> 
> From: Werner Keil 
> Sent: Wednesday, November 7, 2018 9:43:13 AM
> To: dev@tamaya.incubator.apache.org
> Subject: Re: RFC: Draft for report - will submit at 2018-11-06
>
> Btw both the contribution activity in JSR 382 (see before) and MicroProfile
> Config: https://github.com/eclipse/microprofile-config/graphs/contributors
> have massively decreased since a peak about a year ago.
> And there are just 2 who contributed more than 5k LOC, 2 (including John)
> with up to 1.5k LOC and the rests is irrelevant with sometimes only a
> character or two contributed.
>
> Compared to both of them Tamaya looks quite good:
> https://github.com/apache/incubator-tamaya/graphs/contributors
> 2 contributed over 20k LOC, 1 over 5k and 2 others over 1.5k over the
> history of the project.
>
> I did not realize how much William has done, so why haven't we voted on his
> committer role already?
>
> Werner
>
>
>
>
> On Wed, Nov 7, 2018 at 4:32 PM Werner Keil  wrote:
>
> > Phil mentioned two possible committers.
> > Not sure if they meet requirements by ASF based on their existing
> > contributions like JIRA, etc. to be nominated right now?
> >
> > Anatole mentioned support for both JSR 382 and MicroProfile config.
> > However the Config standardization efforts are totally fragmented between
> > JSR 382, MicroProfile Config and a few others like DeltaSpike.
> > MicroProfile Config like most MP efforts is a 1-3 person gig, so not much
> > difference to Tamaya. The JSR is canibalized by that because the same
> > people have to take care of both:
> > https://github.com/eclipse/ConfigJSR/graphs/contributors shows there are
> > just 2 who contributed beyond 5k LOC, one about 1.5k and everyone else
> less
> > than half of that at most.
> > The JSR should long have undergone a Renewal Ballot as per JCP.next rules
> > (it's 13 months now since the creation on Oct 9, 2017, JCP.next mandates
> a
> > Renewal Ballot after 9 months) but nobody seems to have started that, nor
> > is Spec Lead organization Eclipse sure, what to do with it. I know from
> the
> > Jakarta EE Spec Committee, that David/Tomitribe put the idea of a
> > "jakarta.config" on the table, but that has not been decided on either.
> > MicroProfile Config will never be a "standard", so the decision is
> between
> > putting enough life into the JSR to pass the Renewal Ballot and go Final
> > and Withdraw it.
> >
> > Then a downstream project like Tamaya had to implement yet another 3rd
> API
> > and abandon at least one or both others it used so far.
> > I d

Re: RFC: Draft for report - will submit at 2018-11-06

[Werner Keil]

Btw both the contribution activity in JSR 382 (see before) and MicroProfile
Config: https://github.com/eclipse/microprofile-config/graphs/contributors
have massively decreased since a peak about a year ago.
And there are just 2 who contributed more than 5k LOC, 2 (including John)
with up to 1.5k LOC and the rests is irrelevant with sometimes only a
character or two contributed.

Compared to both of them Tamaya looks quite good:
https://github.com/apache/incubator-tamaya/graphs/contributors
2 contributed over 20k LOC, 1 over 5k and 2 others over 1.5k over the
history of the project.

I did not realize how much William has done, so why haven't we voted on his
committer role already?

Werner




On Wed, Nov 7, 2018 at 4:32 PM Werner Keil  wrote:

> Phil mentioned two possible committers.
> Not sure if they meet requirements by ASF based on their existing
> contributions like JIRA, etc. to be nominated right now?
>
> Anatole mentioned support for both JSR 382 and MicroProfile config.
> However the Config standardization efforts are totally fragmented between
> JSR 382, MicroProfile Config and a few others like DeltaSpike.
> MicroProfile Config like most MP efforts is a 1-3 person gig, so not much
> difference to Tamaya. The JSR is canibalized by that because the same
> people have to take care of both:
> https://github.com/eclipse/ConfigJSR/graphs/contributors shows there are
> just 2 who contributed beyond 5k LOC, one about 1.5k and everyone else less
> than half of that at most.
> The JSR should long have undergone a Renewal Ballot as per JCP.next rules
> (it's 13 months now since the creation on Oct 9, 2017, JCP.next mandates a
> Renewal Ballot after 9 months) but nobody seems to have started that, nor
> is Spec Lead organization Eclipse sure, what to do with it. I know from the
> Jakarta EE Spec Committee, that David/Tomitribe put the idea of a
> "jakarta.config" on the table, but that has not been decided on either.
> MicroProfile Config will never be a "standard", so the decision is between
> putting enough life into the JSR to pass the Renewal Ballot and go Final
> and Withdraw it.
>
> Then a downstream project like Tamaya had to implement yet another 3rd API
> and abandon at least one or both others it used so far.
> I don't think the pressure is really on Tamaya at this point and it seems
> the decisions for the Config spec will be made any time soon.
>
> So taking the offer of two or three committers looks like a good idea.
> IMO I would mention the upstream config API problem in a few words, it is
> nothing Tamaya itself can solve, but it has an impact also on the pace at
> which new releases make sense.
>
> Regards,
>
> Werner
>
>
>
>
> On Wed, Nov 7, 2018 at 5:50 AM John D. Ament 
> wrote:
>
>> I've signed off on the report.  However, there were a lot of merge
>> conflicts so if you could please double check.
>>
>> I'm concerned about the strength of the project.  It's basically a 2
>> person
>> team.  What can we do to try to grow the community?
>>
>> John
>>
>> On Tue, Nov 6, 2018 at 5:36 PM P. Ottlinger 
>> wrote:
>>
>> > Am 06.11.18 um 22:06 schrieb Justin Mclean:
>> > > Just a friendly reminder that the report is due today - don't forget
>> to
>> > submit it.
>> >
>> > Thanks,
>> > done:
>> > https://wiki.apache.org/incubator/November2018
>> >
>> > n8
>> > Phil
>> >
>>
>

Re: RFC: Draft for report - will submit at 2018-11-06

[Werner Keil]

Phil mentioned two possible committers.
Not sure if they meet requirements by ASF based on their existing
contributions like JIRA, etc. to be nominated right now?

Anatole mentioned support for both JSR 382 and MicroProfile config.
However the Config standardization efforts are totally fragmented between
JSR 382, MicroProfile Config and a few others like DeltaSpike.
MicroProfile Config like most MP efforts is a 1-3 person gig, so not much
difference to Tamaya. The JSR is canibalized by that because the same
people have to take care of both:
https://github.com/eclipse/ConfigJSR/graphs/contributors shows there are
just 2 who contributed beyond 5k LOC, one about 1.5k and everyone else less
than half of that at most.
The JSR should long have undergone a Renewal Ballot as per JCP.next rules
(it's 13 months now since the creation on Oct 9, 2017, JCP.next mandates a
Renewal Ballot after 9 months) but nobody seems to have started that, nor
is Spec Lead organization Eclipse sure, what to do with it. I know from the
Jakarta EE Spec Committee, that David/Tomitribe put the idea of a
"jakarta.config" on the table, but that has not been decided on either.
MicroProfile Config will never be a "standard", so the decision is between
putting enough life into the JSR to pass the Renewal Ballot and go Final
and Withdraw it.

Then a downstream project like Tamaya had to implement yet another 3rd API
and abandon at least one or both others it used so far.
I don't think the pressure is really on Tamaya at this point and it seems
the decisions for the Config spec will be made any time soon.

So taking the offer of two or three committers looks like a good idea.
IMO I would mention the upstream config API problem in a few words, it is
nothing Tamaya itself can solve, but it has an impact also on the pace at
which new releases make sense.

Regards,

Werner




On Wed, Nov 7, 2018 at 5:50 AM John D. Ament  wrote:

> I've signed off on the report.  However, there were a lot of merge
> conflicts so if you could please double check.
>
> I'm concerned about the strength of the project.  It's basically a 2 person
> team.  What can we do to try to grow the community?
>
> John
>
> On Tue, Nov 6, 2018 at 5:36 PM P. Ottlinger  wrote:
>
> > Am 06.11.18 um 22:06 schrieb Justin Mclean:
> > > Just a friendly reminder that the report is due today - don't forget to
> > submit it.
> >
> > Thanks,
> > done:
> > https://wiki.apache.org/incubator/November2018
> >
> > n8
> > Phil
> >
>

Re: [ANNOUNCE] Commons Configuration 2.4 Released

[Werner Keil]

Phil,

Not at all. At least when I last looked at it, Commons Config 2 shows a
great improvement over V1, somewhat similar to e.g. the step up from Log4J
1 to Log4J2. However, its API does not seem to implement either
MicroProfile Config, JSR 382 or (a not yet existing) Jakarta EE Config. And
frankly until that fragmentation is settled either way nobody can blame
them.

It does not really compare to Tamaya directly either. What Tamaya does on
top of its own API or others (like both MP Config and JSR 382 at this
point) is comparable to Netflix Archaius. Which builds a Cloud-friendly
distributed configuration layer on top of Commons Config, but a bit more
recently also added support for e.g. Typesafe Config. So Archaius is closer
to Tamaya while Commons Config is the default underlying "low level"
framework for Archaius.

HTH,
Werner



On Tue, Oct 30, 2018 at 8:21 PM P. Ottlinger  wrote:

> Does anyone know how this project relates to Tamaya or Microprofile Config?
>
> Cheers,
> Phil
>
>
>  Weitergeleitete Nachricht 
> Betreff: [ANNOUNCE] Commons Configuration 2.4 Released
> Datum: Tue, 30 Oct 2018 10:57:26 -0400
> Von: Rob Tompkins 
> An: annou...@apache.org, Commons Developers List
> , Commons Users List 
>
> The Apache Commons Team is pleased to announce the release of
> Apache Commons Configuration 2.4.
>
> The Apache Commons Configuration open source software library provides a
> generic configuration interface which enables an application to read
> configuration data from a variety of sources.
>
> Source and binary distributions are available for download from the Apache
> Commons download site:
>
>
> http://commons.apache.org/proper/commons-configuration/download_configuration.cgi
>
> When downloading, please verify signatures using the KEYS file available at
> the above location when downloading the release.
>
> Alternatively the release can be pulled via maven:
>   org.apache.commons
>   commons-configuration2
>   2.4
>
> The release notes can be reviewed at:
>   http://www.apache.org/dist/commons/configuration/RELEASE-NOTES.txt
>
> For complete information on Commons Configuration, including
> instructions on how to
> submit bug reports, patches, or suggestions for improvement, see the Apache
> Commons Configuration website:
>
> http://commons.apache.org/proper/commons-configuration/
>
> Best regards,
> Rob Tompkins
> on behalf of the Apache Commons community
>

Re: Important changes

[Werner Keil]

So I guess we try go get Tamaya graduated here eventually?

If a clarification of a more distinct config spec than the "Trinity" that's
cultivated right now happens before that, it certainly won't hurt ;-)

@Anatole All the best.

Werner




On Sun, Oct 7, 2018 at 3:36 PM Anatole Tresch  wrote:

> Hi William
>
> Ill make ir short, since I am a bit sick today...
>
> As of now the format modules do not support things, like Json arrays and
> Yaml lists properly. There is another ticket for that.
>
> Actually I have implemented this ticket already, but not yet committed,
> because I also was playing around with another other ticket for better
> classloading support (I know mixing up tickets is bad practice, ashes on my
> head)...
>
> I think I will be back to notmal soon, so I can create a branch...
>
> Ok? J Anatole
>
>
>
> William Lieurance  schrieb am So., 7. Okt.
> 2018, 12:08:
>
> > Hi there,
> >
> > I took a stab at TAMAYA-355, the multi-value mapping ticket, and had a
> > question.
> >
> > Anatole, you mention that there's somewhere in core that supports mapping
> > that includes nested elements, but I can't find it.  Where did you mean?
> > I've got the json and yaml extensions found, but am missing that
> > XML-looking config format in the ticket.
> >
> > I'm excited that we're pushing towards another release. :-)
> >
> > --William
> >
> >
> >
> > 
> > From: Anatole Tresch 
> > Sent: Thursday, September 27, 2018 1:14 PM
> > To: dev@tamaya.incubator.apache.org
> > Subject: Important changes
> >
> > Hi guys,
> >
> > I have added three ticket I like to be discussed, which I think together
> > with other open issues would be a good package for the next release. So
> > have a look at and comment on:
> >
> > https://issues.apache.org/jira/browse/TAMAYA-355
> > https://issues.apache.org/jira/browse/TAMAYA-354
> > https://issues.apache.org/jira/browse/TAMAYA-353
> > 
> >
> > J Anatole
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com  *
> > *Twitter:  @atsticks, @tamayaconf*
> > [image: JVM Con]
> >
>

Re: Improving our Community

[Werner Keil]

Unfortunately the fragmentation and internal competition between JSR 382,
MicroProfile Config, Geronimo Config, DeltaSpike Config and at Apache alone
at least Commons Config 2 and Tamaya, make it harder for all involved
projects to reach a broader audience.

Cheers,
Werner



On Sun, Sep 30, 2018 at 8:18 PM P. Ottlinger  wrote:

> Am 28.09.2018 um 05:25 schrieb Anatole Tresch:
> > Furthermore we really must get in touch with all people that helped us
> with
> > the project as of now. I was quite offline because of holidays, sorry for
> > that. I propose, we do a *Hangout *to get to know each other better and
> > possibly see who can do what. *So can every body send me the preferred
> > times/timezone, so I can try to setup a hangout or Doodle?* Would be
> great!
>
> +1
>
> I think we have a viable product that needs a broader audience :-)
>
> Cheers,
> Phil
>

RE: Nest steps

[Werner Keil]

Yes, also did that for the JSR 385 API similar to JavaMoney.

Werner

Sent from Mail for Windows 10

From: Anatole Tresch
Sent: Thursday, May 10, 2018 18:29
To: dev@tamaya.incubator.apache.org
Cc: P. Ottlinger
Subject: Re: Nest steps

Its basically simple:

   - Add module-info.java files.
   - Use JDK9 for building.
   - First run maven-compiler with a Java9 target for ALL source files.
   - Second run maven-compiler with Java8 target, exluding the not
   compilable module-info.java

As a result you get Java 8 compatible class files, with a Java 9
module-info.class (ignored by Java 8).

So basically quite simple...

J Anatole

Am Do., 10. Mai 2018 um 00:53 Uhr schrieb Oliver B. Fischer <
o.b.fisc...@swe-blog.net>:

> I will spend today some time to understand you Anatole did it for Java
> Money.
>
> Oliver
>
> Am 07.05.18 um 22:02 schrieb P. Ottlinger:
> > Hi *,
> >
> > Am 06.05.2018 um 18:54 schrieb Anatole Tresch:
> >> Maybe I didnt get the point. We talk about full module support. The JSR
> >> branch I would release when the JSRs EDR is out...
> >
> > Thanks for clearing the order of work ...
> >
> > @Oliver, go ahead and create a ticket :-) Nice that you are back.
> >
> > Cheers,
> > Phil
> >
>


-- 
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com  *
*Twitter:  @atsticks, @tamayaconf*

*Speaking at:*

  [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]

RE: Java 9 & 10

[Werner Keil]

Actually a Multi-Release JAR if we found that useful (with a new JDK every 6 
months it seems tempting or even inevitable) is not built with Java 9 or 10, 
the plugin states it should be with Java 8, but thanks to the Multi-release 
feature and META-INF it’ll work with different versions. 

I am not sure, how it deals with e.g. a class that relies on entirely new 
language Features of Java 10 or 11 like „var“ etc. that someone has to find 
out. I tried to build JARs with a module-info under JDK9 and it would no longer 
run on a JVM before Java 9. 

I don’t think we want to be trapped in a Java „Version-Hell“ so at least Java 8 
should still work for some time as the Minimum Version.

Werner

From: Aaron Coburn
Sent: Tuesday, March 6, 2018 21:01
To: dev@tamaya.incubator.apache.org
Subject: Re: Java 9 & 10

Hi,

Travis-CI currently supports Java 9 builds, which would be simple to add to the 
current .travis.yml configuration. It is possible to test Java 10 on Travis but 
it requires some acrobatics (find the latest EA version by parsing some HTML, 
download the JDK artifact and then install it). Including CI support for JDK 10 
is most likely not worth the effort in the context of Travis.

For the Apache Jenkins infrastructure, it seems that Java 9 and 10 are both 
available: 
https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix 


Regards,
Aaron

> On Mar 6, 2018, at 2:17 PM, Oliver B. Fischer  
> wrote:
> 
> Hi Aaron,
> 
> as far I know we don't have any CI job for Java 9 or 10. So it would be 
> difficult to maintain such changes without breaking it.
> 
> I could check Apache's Jenkins if both JDK versions available on Jenkins.
> 
> Best,
> Oliver
> 
> Am 05.03.18 um 15:53 schrieb Aaron Coburn:
>> Hi,
>> I am a bit new to Tamaya, so apologies if this has already been discussed. 
>> It is clear that the codebase targets Java 8. It is also entirely _usable_ 
>> on newer (jdk9 & jdk10) platforms. However, it is not currently possible to 
>> build Tamaya on jdk9 or jdk10. My first question is: should it be possible 
>> to build Tamaya on the latest JDK?
>> In fact, the only impediment to building on jdk9 is the karaf-maven-plugin. 
>> In particular, some Java EE libraries are no longer on the classpath by 
>> default: javax.xml.bind and javax.activation. With jdk10, these libraries 
>> will no longer be included in the Java SE at all. Adding those dependencies 
>> directly to the plugin configuration or upgrading to the latest (milestone) 
>> Karaf release makes it possible to build on jdk9.
>> Building on jdk10 has the additional problem of the javadoc plugin not being 
>> able to parse the JVM version string with commons-lang 3.5 release. Forcing 
>> the use of commons-lang 3.7 for the plugin solves that.
>> Is this something you all would like to support? I can provide a pull 
>> request for that.
>> The other, related, issue has to do with the Java 9 module system (JSR-376). 
>> Even while targeting JDK 1.8 for the Tamaya codebase, there is a fairly 
>> simple thing that can be done to make the Tamaya codebase easier to use with 
>> the Java 9 module system. Basically, it involves adding a 
>> "Automatic-Module-Name: " entry in the MANIFEST.MF file. 
>> Practically, this means adjusting the various bnd.bnd files in the codebase. 
>> For instance, the tamaya-core JAR would likely have a module name of: 
>> org.apache.tamaya.core (typically, this would align with the existing OSGi 
>> Export-Package). The tamaya-api JAR currently exports two packages (o.a.t 
>> and o.a.t.spi), so perhaps the module name would simply be 
>> org.apache.tamaya? I suspect that the various extensions would make use of 
>> the current OSGi export naming convention for this, as with tamaya-core. If 
>> this is something you'd like to have for the 0.4 release, I can also supply 
>> a pull request for that.
>> Also, I am happy to open JIRA issues for either or both of these items, 
>> though I wasn't sure if you'd like to discuss either of these first.
>> Thanks,
>> Aaron Coburn

Re: Java 9 & 10

[Werner Keil]

Hi,

I raised this for the RI of JSR 385, the upcoming new Units of Measurement
standard 2.0: https://github.com/unitsofmeasurement/indriya/issues/25
If this Maven plugin was acceptable by Apache projects it could be used not
only by Tamaya.

And utilizing the Multi-Release JAR feature of Java 9 would even allow to
include support for Java 7 if we still care or 8 and beyond.

Gunnar is also at JavaLand, so those who are there or at the community
Unconference may get a chance to talk to him about it.

Regards,

Werner


On Mon, Mar 5, 2018 at 4:59 PM, Anatole Tresch  wrote:

> Hi Aaron
>
> thank you very much for your mail.  Both, opening jira, as well as
> providing patches are very welcome, as well ad any other feedback!
>
> Best
> Anatole
>
> Am 05.03.2018 15:53 schrieb "Aaron Coburn" :
>
> > Hi,
> >
> > I am a bit new to Tamaya, so apologies if this has already been
> discussed.
> > It is clear that the codebase targets Java 8. It is also entirely
> _usable_
> > on newer (jdk9 & jdk10) platforms. However, it is not currently possible
> to
> > build Tamaya on jdk9 or jdk10. My first question is: should it be
> possible
> > to build Tamaya on the latest JDK?
> >
> > In fact, the only impediment to building on jdk9 is the
> > karaf-maven-plugin. In particular, some Java EE libraries are no longer
> on
> > the classpath by default: javax.xml.bind and javax.activation. With
> jdk10,
> > these libraries will no longer be included in the Java SE at all. Adding
> > those dependencies directly to the plugin configuration or upgrading to
> the
> > latest (milestone) Karaf release makes it possible to build on jdk9.
> >
> > Building on jdk10 has the additional problem of the javadoc plugin not
> > being able to parse the JVM version string with commons-lang 3.5 release.
> > Forcing the use of commons-lang 3.7 for the plugin solves that.
> >
> > Is this something you all would like to support? I can provide a pull
> > request for that.
> >
> >
> > The other, related, issue has to do with the Java 9 module system
> > (JSR-376). Even while targeting JDK 1.8 for the Tamaya codebase, there
> is a
> > fairly simple thing that can be done to make the Tamaya codebase easier
> to
> > use with the Java 9 module system. Basically, it involves adding a
> > "Automatic-Module-Name: " entry in the MANIFEST.MF file.
> > Practically, this means adjusting the various bnd.bnd files in the
> > codebase. For instance, the tamaya-core JAR would likely have a module
> name
> > of: org.apache.tamaya.core (typically, this would align with the existing
> > OSGi Export-Package). The tamaya-api JAR currently exports two packages
> > (o.a.t and o.a.t.spi), so perhaps the module name would simply be
> > org.apache.tamaya? I suspect that the various extensions would make use
> of
> > the current OSGi export naming convention for this, as with tamaya-core.
> If
> > this is something you'd like to have for the 0.4 release, I can also
> supply
> > a pull request for that.
> >
> > Also, I am happy to open JIRA issues for either or both of these items,
> > though I wasn't sure if you'd like to discuss either of these first.
> >
> > Thanks,
> > Aaron Coburn
>

Fwd: Apache EU Roadshow CFP Closing Soon (23 February)

[Werner Keil]

Hi,

Did someone already propose a Tamaya talk?
I'm afraid, beside DWX in Nuremberg in the last week of June there is an
exact overlap (Apache and Eclipse don't seem to coordinate everywhere as
with the possible "Jakarta EE" name ;-) with EclipseCon France:
https://www.eclipsecon.org/france2018/

So I lean more towards the unconference day there and should I have a talk
in the main conference track, also consider staying an extra day.

What about others including those in Berlin?

Werner


-- Forwarded message --
From: Sharan F 
Date: Wed, Feb 14, 2018 at 4:18 PM
Subject: Apache EU Roadshow CFP Closing Soon (23 February)
To:


Hello Everyone

This is an initial reminder to let you all know that we are holding an
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13th and 14th
June 2018. https://s.apache.org/tCHx

The Call for Proposals (CFP) for the Apache EU Roadshow is currently open
and will close at the end of next week, so if you have been delaying making
a submission because the closing date seemed a long way off, then it's time
to start getting your proposals submitted.

So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so are
looking for projects including incubating ones, to submit presentations,
panel discussions, BoFs, or workshop proposals. The main focus of the
Roadshow will be IoT, Cloud, Httpd and Tomcat so if your project is
involved in or around any of these technologies at Apache then we are
very interested
in hearing from you.

Community and collaboration is important at Apache so if your project is
interested in organising a project sprint, meetup or hackathon during the
Roadshow, then please submit it in the CFP as we do have some space
available to allocate for these.

If you are wanting to submit a talk on open source community related topics
such as the Apache Way, governance or legal aspects then please submit
these to the CFP for FOSS Backstage.

Tickets for the Apache EU Roadshow are included as part of the registration
for FOSS Backstage, so to attend the Roadshow you will need to register for
FOSS Backstage. Early Bird tickets are still available until the 21st
February 2018.

Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow : http://apachecon.com/
euroadshow18/

-  To submit a CFP for FOSS Backstage : https://foss-backstage.de/
call-papers

-  To register to attend the Apache EU Roadshow and/or FOSS Backstage :
https://foss-backstage.de/tickets

For further updates and information about the Apache EU Roadshow please
check http://apachecon.com/euroadshow18/

Thanks
Sharan Foga, VP Apache Community Development

Re: ApacheCon NA in September

[Werner Keil]

Phil,

Let's have a look, I would not mind to propose something if others are not
in town or able to present.

Cheers,
Werner


On Wed, Jan 31, 2018 at 11:10 PM, P. Ottlinger 
wrote:

> Hi,
>
> Am 31.01.2018 um 22:17 schrieb Anatole Tresch:
> > just wanted to inform you that I have submitted a talk for ApacheCon NA
> in
> > September this year in Canada. I think we can show more things in action,
> > also combining Tamaya with ServiceMix, Camel, Karaf etc...
> > I will apply for Travel Assistance as well, but I quite probably I will
> be
> > able to join without as well, when the talk has been accepted.
>
> great news!
>
> +1
>
> > Maybe you guys in Berlin may check the opporunities at the Apache related
> > events in Berlin, see
> > https://cfp.apachecon.com/conference.html?apache-eu-roadshow-2018
>
> Most probably I'll be out of town around that date, but we'll see.
>
> Cheers,
> Phil
>

Re: ApacheCon NA in September

[Werner Keil]

Hi Anatole,

Thanks for the heads-up. Seems in Europe Apache does something like Voxxed
Days as opposed to a full conference?
I'd be happy to propose something with other Tamaya committers for Berlin.
As I seem to be in Germany for most of this year and unless there was
really e.g. a JavaOne talk that justifies going there (not as long as in EC
times ;-) I mostly focus on EMEA events now.

Beside Tamaya I may also propose something on Johnzon/JSON (will ask
Henrik) and Olingo, because I just use it in a Microservice environment
right now.

Regards,
Werner



On Wed, Jan 31, 2018 at 10:17 PM, Anatole Tresch  wrote:

> Hi Guys
>
> just wanted to inform you that I have submitted a talk for ApacheCon NA in
> September this year in Canada. I think we can show more things in action,
> also combining Tamaya with ServiceMix, Camel, Karaf etc...
> I will apply for Travel Assistance as well, but I quite probably I will be
> able to join without as well, when the talk has been accepted.
>
> Maybe you guys in Berlin may check the opporunities at the Apache related
> events in Berlin, see
> https://cfp.apachecon.com/conference.html?apache-eu-roadshow-2018
>
>
> J Anatole
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>
> *Speaking at:*
>

Re: Recent test failures with Extensions

[Werner Keil]

Great stuff. Glad to see the Tamaya team grow. And with a company that
seems to deal with configuration a lot it might also broaden the user base.
If that continues it may also increase chances of graduation.

Cheers,
Werner

On Tue, Jan 23, 2018 at 11:23 PM, P. Ottlinger 
wrote:

> Am 21.01.2018 um 01:32 schrieb William Lieurance:
> > I'm super happy to wander through to code or help out with jira issues
> as I find them.  I'll make comments as I go?  TAMAYA-296 seemed simple
> enough, so I put in some patches that I think cover what's needed.
>
>
> @William:
> will merge your patches tomorrow.
>
> Thanks for scanning the Jira :-)
>
> Cheers,
> Phil
>

Re: Apache Trafodion becomes Top-Level Project - SD Times

[Werner Keil]

Guess as long as 2 or 3 developers keep only the "limbs" of an otherwise
dead Geronimo alive while 2 or 3 others work on Tamaya that could be a bit
hard.

If you look at other JSRs like JSON or CDI there is mostly one
implementation at Apache not
- apache-commons-json
- johnzon
- geronimo-json
...


On Fri, Jan 12, 2018 at 8:07 PM, John D. Ament <johndam...@apache.org>
wrote:

> The project very clearly understands the release model, and communicating
> developer discussions via email.  However, unless we get more contributors
> I don't believe it's possible to graduate.
>
> John
>
> On Fri, Jan 12, 2018 at 1:57 PM Werner Keil <werner.k...@gmail.com> wrote:
>
> > Wonder, when we might see this about Tamaya?
> >
> > https://sdtimes.com/data/apache-trafodion-becomes-top-
> level-project/#.WlkEgCxWl10.gmail
> >
> > Of course the team sounds quite massife at Trafodion, especially from
> > China.
> >
> > Werner
> >
>

Apache Trafodion becomes Top-Level Project - SD Times

[Werner Keil]

Wonder, when we might see this about Tamaya?
https://sdtimes.com/data/apache-trafodion-becomes-top-level-project/#.WlkEgCxWl10.gmail

Of course the team sounds quite massife at Trafodion, especially from China.

Werner

Re: Tamaya implements the JSR's API

[Werner Keil]

I don't think there are any real implementations yet. Maybe Geronimo
Config, but the default also looks more like it's MP Config so far.

Werner


On Thu, Nov 23, 2017 at 11:16 PM, P. Ottlinger 
wrote:

> Hiho,
>
> Am 23.11.2017 um 00:13 schrieb Anatole Tresch:
> > the
> > ​official ​
> > conf
> > ​ig GH repo is:
> > https://github.com/eclipse/ConfigJSR
>
> Thanks,
> I've commented on
> https://github.com/eclipse/ConfigJSR/issues/1
> to ask that we need a build.
>
> Quite strange that no other implementation seems to have our problem of
> not being able to access it via Maven.
>
> HTH
> Phil
>

Re: motivational conference today

[Werner Keil]

Hi,

Sounds great. Will this new conference also have a CFP or tracks
interesting to Tamaya or other technologies?
I was invited to chair the Java Track of DWX '18 once more after 2017 and
probably with MicroProfile/JSR 382 EG reps a talk about configuration may
fit in there quite nicely. I'll try to focus more on EMEA (EU) based events
next years after fellow Tamaya committer (at least according to
http://people.apache.org/committer-index.html#A, he has not contribute so
far) Andres was picked for the EC seat by a coin-flip/luck. So JavaOne is
possible but a lot less likely without a mandatory EC duty.

Werner


On Mon, Nov 20, 2017 at 9:28 PM, P. Ottlinger  wrote:

> Hi,
>
> just wanted to let you know that I was able to take part in today's:
> https://berlinbuzzwords.de/17/news/foss-backstage-micro-
> summit-program-online-now
>
> A micro summit to prepare a new conference in June 2018 in Berlin.
>
> Meeting many ASF people and talking to contributors apart from
> interesting talks made this a very motivational day for me.
>
> Let's keep on rolling!
>
> Phil
>

Re: Reverting Api and Extensions?

[Werner Keil]

After JVMCon?

Am 19.11.2017 23:29 schrieb "Anatole Tresch" :

> BTW, not yet fixed 100%, but it looks that I will be in Berlin on We/Th
> next week...
> I will keep you updated once I go book the flights!
>
> 2017-11-19 23:27 GMT+01:00 Anatole Tresch :
>
> > ;-) I still hope, we can get out the next release until end of November.
> > If things will work again, we will have some doc updates, some tests and
> we
> > will be ready ;-)
> >
> > I also added a simple Spring-Boot example, which can be shown later in a
> > blog (example 5).
> >
> > 2017-11-19 22:41 GMT+01:00 Oliver B. Fischer :
> >
> >> Great to hear. I am keen on writing more tests for us... ;-)
> >>
> >>
> >> Am 19.11.17 um 22:23 schrieb Anatole Tresch:
> >>
> >>> I am working on it... yes. It takes time, keeping fingers crossed
> now...
> >>>
> >>> 2017-11-19 13:03 GMT+01:00 P. Ottlinger :
> >>>
> >>> Am 19.11.2017 um 12:41 schrieb Oliver B. Fischer:
>  Pls don't revert -
>  I fixed the PItest threshold,
>  all other failures are the one's with the CDI extensions,
>  that only seem to have problems on linux slaves.
> 
>  @Anatole: did you recheck whether Windows shows the same behaviour
>  between console maven and IDE?
> 
>  Cheers,
>  Phil
> 
> 
> >>>
> >>>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E o.b.fisc...@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fisc...@jabber.org
> >> X http://xing.to/obf
> >>
> >>
> >
> >
> > --
> > *Anatole Tresch*
> > PPMC Member Apache Tamaya
> > JCP Star Spec Lead
> > *Switzerland, Europe Zurich, GMT+1*
> > *maketechsimple.wordpress.com  *
> > *Twitter:  @atsticks, @tamayaconf*
> >
> > *Speaking at:*
> >
> >   [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]
> >
> >
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>
> *Speaking at:*
>
>   [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]
>

Re: Travis integration working from individual project forks

[Werner Keil]

So Travis works while Jenkins builds for the same artifacts keep failing?

Am 15.11.2017 00:11 schrieb "P. Ottlinger" :

> Hi,
>
> Travis integration seems to be working fine :-)
> At least the first build went through successfully in contrast to the
> current situation on Jenkins 
>
> Not sure if you guys see the result, but it is GREEN:
> https://travis-ci.org/ottlinger/incubator-tamaya
>
> Does anyone know if INFRA can enable Travis access for our root repos?
>
> Cheers + n8
> Phil
>
> PS: I had to create a fork in my private Github account in order to
> verify the travis integration.
>

Re: [DISCUSS] Offering Tamaya as ConfigJSR reference Impl

[Werner Keil]

+1

Speak tomorrow in the EG call

Am 08.11.2017 05:04 schrieb "Anatole Tresch" :

OK, then I will follow up this thing on Thursday with the guys on the EG.
Even is we dont get to be the official implementation, our extensions also
will allow us to outstand IMO ;-)

2017-11-07 23:04 GMT+01:00 Oliver B. Fischer :

> Hi Anatole,
>
> I also think we should go this way and try to become the RI of the JSR
> 382. It took me some time but I think it would be worth it.
>
>
> Oliver
>
>
>
> Am 06.11.17 um 13:27 schrieb Anatole Tresch:
>
>> Hi all
>>
>> As you all know I am also actively joining the current configuration JSR.
>> Summarizing the state can be summarized as follows:
>>
>> - The API as taken over from microprofile.io will be taken as a
>> starting
>> point. We are discussing a few features that also come with Tamaya,
>> overall
>> I don't think the final API will change drastically.
>> - The JSR must select one "official" reference implementation, which
>> must be ALv2 based. The JSRs page will reference multiple reference
>> implementation though, also including Tamaya.
>> - Target is having the JSR finished in 6 months. I think double the
>> time
>> and we have a realistic timeframe, but let's see ;-)
>>
>> ​I will soon add a module in the sandbox, where we implement the new API.
>>
>> Now thinking about this activities I had a somehow crazy idea:
>>
>>
>> - Originally one objective of Tamaya has been to drive forces to get
a
>> config JSR up and running.​ That is now the case.
>> - We still would like to have more attention and being the "official"
>> RI
>> for the config JSR would be an interesting chance to get that.
>> - MP as also now the JSR are doing structurally the same thing. We
>> have
>> some additional features present (some of them like the
>> *ConfigurationContext
>> *are basically not necessary at all).
>>
>> So my thinking was, how can best profit from that situation:
>>
>> - Obviously offer our services to implement the API (already done).
>> - But we could go *one step further *by enabling all our extensions
to
>> work with the new API. If we also get filters as interception
>> mechanism
>> into the JSR (which I think should be possible and makes sense),
>> *building
>> all our extensions on top of the JSR instead of the Tamaya API *is a
>> no
>> brainer.
>> - The *ultimate step* would be to make the JSR the center of our
>> project, thus basically "deprecating" the former Tamaya APIs. We
still
>> would support them by a small compatibility-layer, of course
>> (implemented
>> as extension).
>>
>> What are the advantages and why this discussion?
>>
>>
>> - Depending on we would agree to support also the ultimate step, I
can
>> discuss with the JSR EG that Tamaya might get THE official RI.
>> - All our extensions and integrations would also work with other
>> implementations, which would us put in a similar position that
>> Deltaspike
>> had for CDI. Given that I expect to have a braoder target in the dev
>> 
>> eloper
>> community and maybe also attract additional people to join us in a
>> later
>> step.
>>
>> WDYT?
>>
>> J Anatole
>>
>>
>>
>>
>>
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>


--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com  *
*Twitter:  @atsticks, @tamayaconf*

*Speaking at:*

  [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]

Re: [DISCUSS] Offering Tamaya as ConfigJSR reference Impl

[Werner Keil]

It sounds worth considering.

Of course there has been effort by Mark, Co-Spec Lead of the JSR and mostly
John into Geronimo Config
https://github.com/apache/geronimo-config/graphs/contributors

Compared to the codebase and various extension modules (I would not see
many as part of the RI, but extensions and an ecosystem around it) Tamaya
has
https://github.com/apache/incubator-tamaya/graphs/contributors

there is less involvement in Geronimo.

Since especially John has contributed to both (more LOC in Tamaya) hope he
can tell us what he thinks.

Tamaya despite incubating also has a couple of commercial users already,
while unless TomEE might use it under the hood, Geronimo may not be so
widely used in real applications and projects with actual customers. The
OSGi support Tamaya demonstrated recently is certainly a plus, but can't
say, how important it is for vendors outside IBM/Liberty?
I would certainly talk to Emily what she thinks of the OSGi support, and if
that's something, OpenLiberty might even use instead of creating its own
implementation of JSR 382 (of course that could potentially also be another
good RI candidate, it is Open Source now;-)

Both options seem possible, either Tamaya was seen as a good RI candidate
and also gets used at least by those projects and products that build on
top of Geronimo Config or created their own implementation so far, or it
could be the OpenWebBeans/Johnzon equivalent at Apache like they do as
alternate compatible implementations for CDI or JSON-P/B.

Even if Geronimo was considered the ideal RI, Apache is so diverse, that
you often have two or more solutions for a particular problem.

Werner


On Mon, Nov 6, 2017 at 1:27 PM, Anatole Tresch  wrote:

> Hi all
>
> As you all know I am also actively joining the current configuration JSR.
> Summarizing the state can be summarized as follows:
>
>- The API as taken over from microprofile.io will be taken as a
> starting
>point. We are discussing a few features that also come with Tamaya,
> overall
>I don't think the final API will change drastically.
>- The JSR must select one "official" reference implementation, which
>must be ALv2 based. The JSRs page will reference multiple reference
>implementation though, also including Tamaya.
>- Target is having the JSR finished in 6 months. I think double the time
>and we have a realistic timeframe, but let's see ;-)
>
> ​I will soon add a module in the sandbox, where we implement the new API.
>
> Now thinking about this activities I had a somehow crazy idea:
>
>
>- Originally one objective of Tamaya has been to drive forces to get a
>config JSR up and running.​ That is now the case.
>- We still would like to have more attention and being the "official" RI
>for the config JSR would be an interesting chance to get that.
>- MP as also now the JSR are doing structurally the same thing. We have
>some additional features present (some of them like the
> *ConfigurationContext
>*are basically not necessary at all).
>
> So my thinking was, how can best profit from that situation:
>
>- Obviously offer our services to implement the API (already done).
>- But we could go *one step further *by enabling all our extensions to
>work with the new API. If we also get filters as interception mechanism
>into the JSR (which I think should be possible and makes sense),
> *building
>all our extensions on top of the JSR instead of the Tamaya API *is a no
>brainer.
>- The *ultimate step* would be to make the JSR the center of our
>project, thus basically "deprecating" the former Tamaya APIs. We still
>would support them by a small compatibility-layer, of course
> (implemented
>as extension).
>
> What are the advantages and why this discussion?
>
>
>- Depending on we would agree to support also the ultimate step, I can
>discuss with the JSR EG that Tamaya might get THE official RI.
>- All our extensions and integrations would also work with other
>implementations, which would us put in a similar position that
> Deltaspike
>had for CDI. Given that I expect to have a braoder target in the
> developer
>community and maybe also attract additional people to join us in a later
>step.
>
> WDYT?
>
> J Anatole
>
>
>
>
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>
> *Speaking at:*
>
>   [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]
>

Re: Microprofile TCK now running

[Werner Keil]

Cool, that will be great news for upcoming conference talks about it.

Werner


On Fri, Oct 13, 2017 at 1:24 AM, Anatole Tresch  wrote:

> Hi all,
>
> it was a bit harder than originally thaught, but with the fix of some
> issues on MP and the OptionalConverter we now have the MP Configuration 1.1
> API's TCK running (despite the one case, where Tamaya provides more
> functionality and the MP TCK should be fixed).
>
> So we are now compatible with MP in the sandbox ;-)
>
> J Anatole
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>
> *Speaking at:*
>
>   [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]
>

Re: Anyone looking at this PR?

[Werner Keil]

Probably another reason why Java EE went to Eclipse.

There fully Github based repos become the norm for most new projects.

Am 07.10.2017 11:42 schrieb "P. Ottlinger" :

> Hi,
>
> maybe we are still not really understanding each other.
> I was of the impression that ASF provides an interface similar to github
> to review, discuss, comment, change PRs 
> if I understand your answer correctly this is not the case.
>
> Thus I'd personally love the possibility to interact with ASF-repos via
> github, since it's much more convenient.
>
> Any other opinions on that?
>
> Thanks,
> Phil
>
> Am 06.10.2017 um 02:47 schrieb John D. Ament:
> > Take a look at [1].  When I created the PR, the email sent included
> > instructions how to merge the PR, even if we don't have write access.
> "git
> > pull https://github.com/apache/incubator-tamaya-sandbox
> TAMAYA-260-mp-11"
> >
> > Now, back when Tamaya was started ASF didn't support writable github.
> Now
> > it does.  Is it something we're interested in?
>
>

[jira] [Updated] (TAMAYA-313) Evaluate Java 9 Multi-release JAR feature

[Werner Keil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TAMAYA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Keil updated TAMAYA-313:
---
Summary: Evaluate Java 9 Multi-release JAR feature  (was: Evaluate Java 9 
Multi-version JAR feature)

> Evaluate Java 9 Multi-release JAR feature
> -
>
> Key: TAMAYA-313
> URL: https://issues.apache.org/jira/browse/TAMAYA-313
> Project: Tamaya
>  Issue Type: Task
>    Reporter: Werner Keil
>
> Java 9 comes with a Multi-version JAR file feature where classes for multiple 
> Java versions can be packed into the same JAR file. This may allow 
> backward-compatibility with Java 8 or 7 in the same JAR.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TAMAYA-313) Evaluate Java 9 Multi-version JAR feature

[Werner Keil (JIRA)]

Werner Keil created TAMAYA-313:
--

 Summary: Evaluate Java 9 Multi-version JAR feature
 Key: TAMAYA-313
 URL: https://issues.apache.org/jira/browse/TAMAYA-313
 Project: Tamaya
  Issue Type: Task
Reporter: Werner Keil


Java 9 comes with a Multi-version JAR file feature where classes for multiple 
Java versions can be packed into the same JAR file. This may allow 
backward-compatibility with Java 8 or 7 in the same JAR.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: JSR 382

[Werner Keil]

Oliver/all,

I saw the invitation to BEDCon:
http://bed-con.org/2017/programm

Thanks, but my schedule for Sep/Oct is already much too busy with JavaOne
and 3(!) other conferences in October.

Ondrej Mihályi <http://bed-con.org/2017/speaker#Ondrej-Mihályi> will talk
about MicroProfile on Friday. Maybe you could speak to him about synergies
between Tamaya and MicroProfile Config. He has been fairly active in the MP
Config project.

Speak later,
Werner


On Wed, Sep 13, 2017 at 11:48 PM, Anatole Tresch <atsti...@gmail.com> wrote:

> Thanks, Werner. Good news!
>
> 2017-09-13 11:14 GMT+02:00 Werner Keil <werner.k...@gmail.com>:
>
> > Guys,
> >
> > Looks like a couple of JSRs beside Java SE (.next) were filed this week:
> > https://jcp.org/en/jsr/detail?id=382
> >
> > It is up to the PMO who Emily and Mark represent (I know, for a long time
> > he represented Apache Foundation;-) but someone from Tamaya, ideally
> > Anatole (representing Trivadis, not CS :-D) should join this EG.
> >
> > I am more keen on JSR 381 (VisRec) and very soon we should have an
> updated
> > Unit JSR (to cope with the new SI standard in about a year) but either as
> > EG Member or Contributor I am sure, I'll also provide input or help if
> > needed.
> >
> > That also answers the question how long to wait with graduation. As soon
> as
> > a JSR number is defined and the JSR approved (with decent work done at
> > Eclipse I have no doubt, it can pass) Tamaya can adapt it wherever it
> makes
> > sense.
> >
> > Also good to discuss in the next hangout.
> >
> > Cheers,
> > 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*
>
> *Speaking at:*
>
>   [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]
>

JSR 382

[Werner Keil]

Guys,

Looks like a couple of JSRs beside Java SE (.next) were filed this week:
https://jcp.org/en/jsr/detail?id=382

It is up to the PMO who Emily and Mark represent (I know, for a long time
he represented Apache Foundation;-) but someone from Tamaya, ideally
Anatole (representing Trivadis, not CS :-D) should join this EG.

I am more keen on JSR 381 (VisRec) and very soon we should have an updated
Unit JSR (to cope with the new SI standard in about a year) but either as
EG Member or Contributor I am sure, I'll also provide input or help if
needed.

That also answers the question how long to wait with graduation. As soon as
a JSR number is defined and the JSR approved (with decent work done at
Eclipse I have no doubt, it can pass) Tamaya can adapt it wherever it makes
sense.

Also good to discuss in the next hangout.

Cheers,
Werner

Re: Hangout next week (2017-09-11)

[Werner Keil]

Me too, next week should work.

Werner


On Mon, Sep 4, 2017 at 8:07 PM, P. Ottlinger  wrote:

> Am 04.09.2017 um 16:29 schrieb Oliver B. Fischer:
> > WDYT? 8 pm?
>
> sounds good to me since I'm quite busy this week.
>
> Cheers,
> Phil
>

Re: Scope of Tamaya 0.4

[Werner Keil]

Hi,

Does the MicroProfile extension module implement the current API and pass
TCKs?

If so, it could be worth mentioning it under
https://github.com/eclipse/microprofile-config
(Tamaya is already an influence, but if parts implement the API why not
also add this fact in the Readme)

Werner


On Thu, Aug 10, 2017 at 1:09 AM, Anatole Tresch  wrote:

> Dear all,
>
> I merged John's code and further improved the implementation. We still have
> some issues, but the microprofie TCK looks muich better now:
>
> [main] INFO org.apache.maven.plugin.surefire.SurefirePlugin - Results:
> [main] INFO org.apache.maven.plugin.surefire.SurefirePlugin -
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin - Failures:
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin -
> AutoDiscoveredConfigSourceTest>Arquillian.run:164->
> testAutoDiscoveredConverterNotAddedAutomatically:81
> The auto discovered converter should not be added automatically.
> -> Problem is that Tamaya iss incredible good and figures out hot the Pizza
> class can be instantiated and creates a on-the-fly converter ;)
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin -
> CDIPlainInjectionTest.arquillianBeforeClass » Deployment WELD-001409:
> Ambiguou...
> -> CDI issue to be solved in Tamaya, tbd
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin -
> CdiOptionalInjectionTest.arquillianBeforeClass » Deployment WELD-001408:
> Unsat...
> -> CDI issue to be solved in Tamaya, there is an OptionalConverter...
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin -
> ConfigProviderTest>Arquillian.run:164->testInjectedConfigSerializable:135
> Injected config should be serializable, but could not serialize it
> -> In Tamaya Config instances are not serializable, but MP requires to do
> so, to be fixed...
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin -
> ConverterTest>Arquillian.run:164->testBoolean:217 » IllegalArgument
> Invalid
> ty...
> -> Tamaya refuses to convert 17 to something. The boolean converter
> converts 0 and 1, but does not return false as "default" for anything else.
> I think Tamaya's way o handle that is much more cleaner ;)
> [main] INFO org.apache.maven.plugin.surefire.SurefirePlugin -
> [main] ERROR org.apache.maven.plugin.surefire.SurefirePlugin - *Tests run:
> 46, Failures: 5, Errors: 0, Skipped: 5*
> [main] INFO org.apache.maven.plugin.surefire.SurefirePlugin -
> [main] INFO org.apache.maven.cli.event.ExecutionEventLogger -
> 
>
> Enjoy your day!
> Anatole
>
>
> 2017-08-09 12:34 GMT+02:00 John D. Ament :
>
> > I just pushed up a branch with MP support.  TCK runs against Weld right
> now
> > (failing).  Give it a shot, let me know if that helps can easily be
> merged
> > to master (but looks like its pointing to Tamaya 0.3 instead of 0.4?)
> >
> > John
> >
> > On Wed, Aug 9, 2017 at 6:19 AM Anatole Tresch 
> wrote:
> >
> > > Basically a good idea. We might also add the vertx support, because its
> > > already there and ready. microprofile is also mostly working, but
> getting
> > > the Arquillian TCK running is not trivial, so lets postpone that
> feature
> > > for 0.5 ;)
> > >
> > > Am 09.08.2017 10:11 schrieb "Oliver B. Fischer" <
> > o.b.fisc...@swe-blog.net
> > > >:
> > >
> > > > Dear all,
> > > >
> > > > to increase our release rate I would like to suggest the following as
> > > only
> > > > feature for 0.4: Switching to Java 8 and some bug fixes. Not other
> > > features.
> > > >
> > > > This would help us to release a new version soon.
> > > >
> > > > WDYT?
> > > >
> > > > Oliver
> > > >
> > > >
> > > > --
> > > > N Oliver B. Fischer
> > > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > > P +49 30 44793251 <+49%2030%2044793251>
> > > > M +49 178 7903538 <+49%20178%207903538>
> > > > E o.b.fisc...@swe-blog.net
> > > > S oliver.b.fischer
> > > > J oliver.b.fisc...@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  *
> *Twitter:  @atsticks, @tamayaconf*
>
>   [image: GeeCON] [image: JSD_Speaker_2017]
>

Re: [Result] Re: [VOTE] Release of Apache Tamaya Extensions 0.3-incubating, Vote I

[Werner Keil]

Thanks,
Wouldn't it be 5 binding or 4+1 right now? In the Podling everyone seems in
that PPMC until eventually the project graduates.

Werner



On Sun, Jul 16, 2017 at 9:43 PM, Oliver B. Fischer <o.b.fisc...@swe-blog.net
> wrote:

>
> Thank you for voting!
>
> 3 binding +1 votes (pmc):
> - Anatole
> - Philipp
> - Oliver
> - John
> - Werner
>
> 0 non-binding +1 votes:
>
> 0 -1 votes:
>
> I will prepare now the vote for the IPMC.
>
> Oliver
>
>
> Am 12.07.17 um 11:06 schrieb Werner Keil:
>
>> +1
>>
>>
>> On Wed, Jul 12, 2017 at 2:34 AM, John D. Ament <johndam...@apache.org>
>> wrote:
>>
>> +1 to release
>>>
>>> Checked rat, verified signatures.
>>>
>>> On Tue, Jul 11, 2017 at 6:08 PM Oliver B. Fischer <
>>> o.b.fisc...@swe-blog.net>
>>> wrote:
>>>
>>> orgapachetamaya-1033
>>> incubating/extensions/
>>> tamaya-extensions.git;a=commit;h=ffe1ed1fe6b6d96be7b0f7c96be
>>> 64ead0198dcd4
>>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
>
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: [VOTE] Release of Apache Tamaya Extensions 0.3-incubating, Vote I

[Werner Keil]

+1


On Wed, Jul 12, 2017 at 2:34 AM, John D. Ament 
wrote:

> +1 to release
>
> Checked rat, verified signatures.
>
> On Tue, Jul 11, 2017 at 6:08 PM Oliver B. Fischer <
> o.b.fisc...@swe-blog.net>
> wrote:
>
> > Hi,
> >
> > I was running the needed tasks to get the 0.3-incubating release of
> > Apache Tamaya Extensions out.
> > The artifacts are deployed to Nexus [1] and releases [3].
> >
> > The tag is available at [3] and will renamed once the vote passed.
> >
> > Please take a look at the artifacts and vote!
> >
> > Please note:
> > This vote is a "majority approval" with a minimum of three +1 votes (see
> > [4]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> > and why..
> > 
> >
> > Thanks,
> > Oliver
> >
> > [1]https://repository.apache.org/content/repositories/
> orgapachetamaya-1033
> > [2]
> >
> > https://dist.apache.org/repos/dist/dev/incubator/tamaya/0.3-
> incubating/extensions/
> > [3]
> >
> > https://git1-us-west.apache.org/repos/asf?p=incubator-
> tamaya-extensions.git;a=commit;h=ffe1ed1fe6b6d96be7b0f7c96be64ead0198dcd4
> > [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251 <+49%2030%2044793251>
> > M +49 178 7903538 <+49%20178%207903538>
> > E o.b.fisc...@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fisc...@jabber.org
> > X http://xing.to/obf
> >
> >
>

Re: 2017-07-10 hangout minutes

[Werner Keil]

Sorry did not hear it:-/


On Mon, Jul 10, 2017 at 10:08 PM, P. Ottlinger 
wrote:

> Hi,
>
> today's meeting took place with:
> * Anatole, Oliver and Phil
>
> AGENDA:
> * Release status
> ** Release of TamayaCORE is approved by the IPMC - ok
> ** Vote01 will take place in this week for 0.3-SNAPSHOT of extensions
> module (Oliver)
>
> * Homepage status
> ** Overhaul of the release guide - Oliver
> ** Publishing the releases makes only sense if extensions is done ->
> thus we await the release before starting to write announcement mails to
> ASF mailinglists
> ** blog series to show advantages of Tamaya - Anatole (we want to
> provide solution-based examples, approx. 10 articles)
> ** example projects should be put into the sandbox module
>
> * Misc
> ** Sandbox - Phil will disable the failing OSGITest
> (https://issues.apache.org/jira/browse/TAMAYA-276) - done
> ** Future versions
> ** 0.4: Java8 and bugfixes
> ** 0.5 Microprofile.io implementation
> The Java8 support will bring a better integration with Vert.x.
> AS soon as we have Java8 we want to implement the microprofile-API draft.
>
>
> Cheers,
> Phil
>

Re: Hangout next Monday, 12. June

[Werner Keil]

+1

Werner


On Mon, Jun 12, 2017 at 8:11 AM, Oliver B. Fischer  wrote:

> Great,
>
> so we will talk at eight.
>
>
> cu
>
>
> Am 07.06.17 um 09:59 schrieb Oliver B. Fischer:
>
> WDYT?
>>
>> Von meinem iPhone gesendet
>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: Podling Report Reminder - June 2017

[Werner Keil]

I assume the 0.3 release and probably what's happening with JBake could be
enough news?

Werner


On Thu, Jun 8, 2017 at 2:46 AM,  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 21 June 2017, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, June 07).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/June2017
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: [Vote] webpage change - move to jbaked version?

[Werner Keil]

+1

I looked at the JBake page from my Android mobile this morning and it does
not render that well compared to the current one, but for the sake of being
up to date, I think the JBake one is an improvement (and some CSS/Bootstrap
"magic" could probably also address issues on mobile browsers or tablets if
we want to support them)

Werner


On Sun, May 28, 2017 at 10:40 PM, P. Ottlinger 
wrote:

> Hi guys,
>
> should I file the INFRA-ticket to change the website to point to the
> contents of:
> https://tamaya.incubator.apache.org/jbake/
>
> under
>
> https://tamaya.incubator.apache.org
>
> This would allow us to instantly release a new blog post once the
> release is out of the door.
>
> WDYT?
> -
> +1
> -1
> 0
> -
>
> Thanks for a response until 20170530 10pm Berlin time.
>
> Cheers
> Phil
>

Re: [VOTE] Release of Apache Tamaya 0.3-incubating

[Werner Keil]

Yes for Maven they should be, but ZIP sounds like a "binary" or "download"
distribution was also created, where I don't think Maven supports you
unless there is a separate Maven resource-plugin or similar to create ZIP
or TAR archives with Maven, too.

Cheers,
Werner


On Wed, May 24, 2017 at 3:01 PM, Anatole Tresch  wrote:

> Normally they are created by the gpg plugin, when the *release* profile is
> active:
>
> mvn clean deploy -DperformRelease=true
>
> J Anatole
>
> 2017-05-24 12:29 GMT+02:00 John D. Ament :
>
> > -1:
> >
> > There's no cryptographic signature files for the .zip and .tar.gz files,
> > which is required for the release.  (it could be they just need to be
> > staged)
> >
> > I see no other issues, so if those files can get staged I'll switch to
> > a +1.  FWIW I don't see those files in the maven staging repo, not sure
> > what goal creates it but usually in maven they end up in the staging repo
> > as well.
> >
> > John
> >
> > On Tue, May 23, 2017 at 4:45 PM Oliver B. Fischer <
> > o.b.fisc...@swe-blog.net>
> > wrote:
> >
> > > Hi,
> > >
> > > I was running the needed tasks to get the 0.3-incubating release of
> > > Apache Tamaya out.
> > > The artifacts are deployed to Nexus [1] and releases [3].
> > >
> > > The tag is available at [3] and will renamed once the vote passed.
> > >
> > > Please take a look at the artifacts and vote!
> > >
> > > Please note:
> > > This vote is a "majority approval" with a minimum of three +1 votes
> (see
> > > [4]).
> > >
> > > 
> > > [ ] +1 for community members who have reviewed the bits
> > > [ ] +0
> > > [ ] -1 for fatal flaws that should cause these bits not to be released,
> > > and why..
> > > 
> > >
> > > Thanks,
> > > Oliver
> > >
> > > [1]
> > > https://repository.apache.org/content/repositories/
> orgapachetamaya-1024/
> > > [2]
> > > https://dist.apache.org/repos/dist/dev/incubator/tamaya/0.3-
> incubating/
> > > [3]
> > >
> > > https://git1-us-west.apache.org/repos/asf?p=incubator-
> > tamaya.git;a=commit;h=c9ee94333bdb2d51e205257b1e746c78261e2c73
> > > [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
> > >
> > >
> > > --
> > > N Oliver B. Fischer
> > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > P +49 30 44793251 <+49%2030%2044793251>
> > > M +49 178 7903538 <+49%20178%207903538>
> > > E o.b.fisc...@swe-blog.net
> > > S oliver.b.fischer
> > > J oliver.b.fisc...@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  *
> *Twitter:  @atsticks, @tamayaconf*
>
>   [image: GeeCON] [image: JSD_Speaker_2017]
>

Re: [VOTE] Release of Apache Tamaya 0.3-incubating

[Werner Keil]

Thanks for pointing that out John.
I know I had to go through that when releasing some artifacts of DeviceMap
while it was active.
No rocket science though, so I would not change the vote and assume
everyone can change theirs if the necessary conditions (like those
signatures) are met.
All Maven repositories at Apache normally get those by default via the
Maven plugins.

Werner

Re: [VOTE] Release of Apache Tamaya 0.3-incubating

[Werner Keil]

+1

Werner


On Tue, May 23, 2017 at 10:45 PM, Oliver B. Fischer <
o.b.fisc...@swe-blog.net> wrote:

> Hi,
>
> I was running the needed tasks to get the 0.3-incubating release of Apache
> Tamaya out.
> The artifacts are deployed to Nexus [1] and releases [3].
>
> The tag is available at [3] and will renamed once the vote passed.
>
> Please take a look at the artifacts and vote!
>
> Please note:
> This vote is a "majority approval" with a minimum of three +1 votes (see
> [4]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released,
> and why..
> 
>
> Thanks,
> Oliver
>
> [1] https://repository.apache.org/content/repositories/orgapache
> tamaya-1024/
> [2] https://dist.apache.org/repos/dist/dev/incubator/tamaya/0.3-
> incubating/
> [3] https://git1-us-west.apache.org/repos/asf?p=incubator-tamaya
> .git;a=commit;h=c9ee94333bdb2d51e205257b1e746c78261e2c73
> [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: Hangout tonight?

[Werner Keil]

Sounds OK, too. I am pretty flexible between now and the second half of
June.
Anatole said, he proposed one or the other topic to Expert Days.
I'd be happy to also do with 2 or 3 key topics I work with or spoke about
already.

Re: Hangout tonight?

[Werner Keil]

I'd be available.

Werner


On Mon, May 15, 2017 at 2:17 PM, Anatole Tresch  wrote:

> How about a short hangout tonight at 20h the latest?
>
> J Anatole
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com  *
> *Twitter:  @atsticks, @tamayaconf*
>
>   [image: GeeCON] [image: JSD_Speaker_2017]
>

Re: Do we need a binary distribution?

[Werner Keil]

Good point.

I don't know if any Apache projects do that by themselves, but in some
cases maybe a Docker image could be a binary distribution to consider.
MavenCentral/Sonatype seems to have lost the lead on that, but Bintray
(their mirror and equivalent to MavenCentral is JCenter) did a lot for
Docker. Performance-co-Pilot has multiple Docker images and also Linux
packages like RPM. Especially the Groovy community loves Bintray,
everything related to Groovy or Gradle can be found there first.



On Wed, May 3, 2017 at 9:22 AM, Anatole Tresch  wrote:

> the fsct is that the bin dist is THE dist. maven downlads sre only
> convenience. btw also with maven the licensing is the same...
>
> Am 03.05.2017 09:08 schrieb "Oliver B. Fischer"  >:
>
> > Hi,
> >
> > John wrote in a comment on TAMAYA-144: " As a reminder, ASF produces
> > source releases not binaries."
> >
> > I never questioned if we need a binary distribution or not. But as we
> also
> > distribute our binaries also via Maven Central may be we should provide
> > only our source distribution?
> >
> > I can't remember when I last time downloaded a jar and added it to the
> > classpath and...
> >
> > WDYT?
> >
> > Oliver
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fisc...@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fisc...@jabber.org
> > X http://xing.to/obf
> >
> >
>

Re: Regarding TAMAYA-144

[Werner Keil]

Was there a hangout today? Did not see a missed reminder.




On Mon, May 1, 2017 at 4:43 PM, Oliver B. Fischer 
wrote:

> So give a hangout call at 6:45. I will be only. I just returned from the
> doctor...
>
>
> Am 01.05.17 um 15:24 schrieb Anatole Tresch:
>
>> I am only availaBLE FOR 20 MINUTES at 5pm, since I will go watching our
>> new
>> kittens afterwards with my kids...
>> Beforehand would be simpler, or later again after 6.45...
>>
>> 2017-05-01 13:43 GMT+02:00 Oliver B. Fischer :
>>
>> Hi Anatole,
>>>
>>> can I call you via Hangout at 5 pm? I am free the whole evening.
>>>
>>> Oliver
>>>
>>>
>>> Am 30.04.17 um 06:19 schrieb Anatole Tresch:
>>>
>>> hi oliver
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fisc...@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fisc...@jabber.org
>>> X http://xing.to/obf
>>>
>>>
>>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: [jira] [Comment Edited] (TAMAYA-144) Ensure correct licensing for binary distribution

[Werner Keil]

Asciidoctor license because of the plugins?
Hate to ask but what about JBake?;-)


On Mon, May 1, 2017 at 5:11 PM, Oliver B. Fischer (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/TAMAYA-144?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15990933#comment-15990933 ]
>
> Oliver B. Fischer edited comment on TAMAYA-144 at 5/1/17 3:10 PM:
> --
>
> Original mail was send by Justin Mclean (jus...@classsoftware.com).
>
>
> was (Author: o.b.fischer):
> Original mail was send by Justin Mclean.
>
> > Ensure correct licensing for binary distribution
> > 
> >
> > Key: TAMAYA-144
> > URL: https://issues.apache.org/jira/browse/TAMAYA-144
> > Project: Tamaya
> >  Issue Type: Bug
> >  Components: API, Docs, Extensions
> >Affects Versions: 0.2-incubating
> >Reporter: Anatole Tresch
> >Assignee: Oliver B. Fischer
> >  Labels: build, tamaya-required-03
> > Fix For: 0.3-incubating
> >
> >   Original Estimate: 24h
> >  Remaining Estimate: 24h
> >
> > The binary LICENSE and NOTICE needs a little work [1], could you please
> fix this for the next release.
> > - LICENSE is missing MIT licensed Asciidoctor and CodeRay (used in docs)
> > - The final jar contains a number of 3rd party licensed software that is
> not mentioned in LICENSE/NOTICE. This includes Dropwizard (Apache license
> with NOTICE file), Jackson Core, Databind and Annotations (Apache), Gogole
> Common libs, Joda Time (Apache with NOTICE), Jackson Afterburner (Apache?),
> slf4j (MIT), Logbock (EPL or GNU), Hibinate Validator (Apache), Glassfish
> (CDDL), Sun Expression Language Reference Implementation (CDDL), snakeyaml
> (Apache), Apache Commons, Jetty (Apache with NOTICE), Jersey (CDDL), H2K
> (CDDL), Javassist (MPL or GPL), Metrics (Apache), argparse4j (MIT),
> Arquillian (Apache?), Shrink-wrap (Apache?), JBoss Modules (Apache), JBoss
> logging (Apache).
> > Most of this is Apache licensed, but there a few NOTICE files that may
> effect your NOTICE [3] and there a couple of MIT licensed file. The CDDL /
> MPL license software which need to treated carefully. [4]
> > I may of missed a couple and you may want to double check the JBoss
> logging as at one point it was GPL not Apache licensed.
> > Thanks,
> > Justin
> > 1. http://www.apache.org/dev/licensing-howto.html#binary
> > 2. ./modules/server/lib/tamaya-server-0.2-incubating.jar
> > 3. http://www.apache.org/dev/licensing-howto.html#alv2-dep
> > 4. http://www.apache.org/legal/resolved.html#category-b
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

Re: Regarding TAMAYA-144

[Werner Keil]

So should we do the hangout at 5pm or is it something in greater detail you
wish to discuss 1on1 that may not be helpful to all participants?

Werner


On Mon, May 1, 2017 at 1:43 PM, Oliver B. Fischer 
wrote:

> Hi Anatole,
>
> can I call you via Hangout at 5 pm? I am free the whole evening.
>
> Oliver
>
>
> Am 30.04.17 um 06:19 schrieb Anatole Tresch:
>
> hi oliver
>>
>> mo is ok. when? it is a free day here in zh...
>> best Anatole
>>
>> Am 30.04.2017 00:11 schrieb "Oliver B. Fischer" > >:
>>
>> Hi all,
>>>
>>> I need someone to discuss https://issues.apache.org/jira
>>> /browse/TAMAYA-144.
>>> We could do it during our regular hangout or separately on Monday.
>>>
>>> Ho would have time for it?
>>>
>>> Oliver
>>>
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fisc...@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fisc...@jabber.org
>>> X http://xing.to/obf
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: Regarding TAMAYA-144

[Werner Keil]

John,

I assume, "repackage" also applies to simple Maven dependencies?
Take Dropwizard support in Parfait:
https://github.com/performancecopilot/parfait/blob/master/parfait-dropwizard/pom.xml
It references 2 libraries from Dropwizard. Doesn't even do a NOTICE file or
something, just using it, like JSR 363 which is also used there.

Regardless of how tedious you end up dealing with those things, the
extension or integration modules for say Dropwizard or JodaTime, JSR 363
(both already are in Sandbox) and many others will require such
dependencies.
Maybe Tamaya "core" can reduce external dependencies, but the extension
libraries can't.

There are Apache projects like SIS (the most popular downstream user of JSR
275) where parts of the project are not even under the Apache license at
all (I'm not even sure, if it's Open Source, but if so it is based on a
proprietary license by some Oil, Gas and Energy standards body) and that
also works fine for SIS  ;-)
It long left the incubator and seems to have quite an impressive number of
contributors: http://sis.apache.org/team-list.html

Werner


On Sun, Apr 30, 2017 at 10:38 AM, Werner Keil <werner.k...@gmail.com> wrote:

> Same here.
>
> Werner
>
>
> On Sun, Apr 30, 2017 at 6:19 AM, Anatole Tresch <atsti...@gmail.com>
> wrote:
>
>> hi oliver
>>
>> mo is ok. when? it is a free day here in zh...
>> best Anatole
>>
>> Am 30.04.2017 00:11 schrieb "Oliver B. Fischer" <o.b.fisc...@swe-blog.net
>> >:
>>
>> > Hi all,
>> >
>> > I need someone to discuss https://issues.apache.org/jira
>> /browse/TAMAYA-144.
>> > We could do it during our regular hangout or separately on Monday.
>> >
>> > Ho would have time for it?
>> >
>> > Oliver
>> >
>> >
>> > --
>> > N Oliver B. Fischer
>> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > P +49 30 44793251
>> > M +49 178 7903538
>> > E o.b.fisc...@swe-blog.net
>> > S oliver.b.fischer
>> > J oliver.b.fisc...@jabber.org
>> > X http://xing.to/obf
>> >
>> >
>>
>
>

Re: Regarding TAMAYA-144

[Werner Keil]

Same here.

Werner


On Sun, Apr 30, 2017 at 6:19 AM, Anatole Tresch  wrote:

> hi oliver
>
> mo is ok. when? it is a free day here in zh...
> best Anatole
>
> Am 30.04.2017 00:11 schrieb "Oliver B. Fischer"  >:
>
> > Hi all,
> >
> > I need someone to discuss https://issues.apache.org/
> jira/browse/TAMAYA-144.
> > We could do it during our regular hangout or separately on Monday.
> >
> > Ho would have time for it?
> >
> > Oliver
> >
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fisc...@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fisc...@jabber.org
> > X http://xing.to/obf
> >
> >
>

Re: Hangout this week?

[Werner Keil]

Sounds like Most of that could go into the Podling Report for May ;-)
Am 27.04.2017 07:50 schrieb "Anatole Tresch" <atsti...@gmail.com>:

> Yep. Basically Oliver will do the release, beforehand also checking that
> all licenses are correctly mentioned in LICENCE. We talked about some
> sandbox modules such as tamaya-metamodel and that we will have to add much
> more tests in the future as well.
> Afterwards release we will switch to Java 8.
>
> J Anatole
>
> 2017-04-26 23:12 GMT+02:00 P. Ottlinger <pottlin...@apache.org>:
>
> > Am 24.04.2017 um 20:07 schrieb Werner Keil:
> > > Guess we're skipping this Week?
> >
> > did you have a meeting yesterday?
> >
> > Any minutes available?
> >
> > Thanks,
> > Phil
> >
> >
> >
>
>
> --
> *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*
>
>   [image: GeeCON]
>

Re: [jira] [Commented] (TAMAYA-144) Ensure correct licensing for binary distribution

[Werner Keil]

Apache Commons, seriously?;-O

Why is that even on the list, at least other ASF projects should be pretty
obvious.

On Wed, Apr 26, 2017 at 11:12 PM, P. Ottlinger 
wrote:

> Hi guys,
>
> what needs to be done here?!
>
> Do we just need to list the licenses or are there licenses in place that
> are not ASF2.0-compliant?
>
> Thanks,
> Phil
>
> Am 26.04.2017 um 22:05 schrieb Oliver B. Fischer (JIRA):
> >
> > [ https://issues.apache.org/jira/browse/TAMAYA-144?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15985470#comment-15985470 ]
> >
> > Oliver B. Fischer commented on TAMAYA-144:
> > --
> >
> > List of mentioned dependencies to be checked:
> >
> > || Dependency   || Core || Extensions ||
> > | Dropwizard  |  |
> > | Jackson Core | |
>

Re: Hangout this week?

[Werner Keil]

Guess we're skipping this Week?

Re: Hangout this week?

[Werner Keil]

Which are the real showstoppers and which can simply be deferred to a later
Release? :-?
Am 20.04.2017 17:53 schrieb "Oliver B. Fischer" <o.b.fisc...@swe-blog.net>:

> Please remember that the *release is blocked* by a lot of resolved and not
> closed issues.
>
> Bye,
>
> Oliver
>
>
> Am 18.04.17 um 22:56 schrieb P. Ottlinger:
>
>> Am 18.04.2017 um 20:33 schrieb Werner Keil:
>>
>>> Do we plan a hangout this week or will it be better next week?
>>>
>> +1 for next week to give Oliver some time to forge the release.
>>
>> Cheers,
>> Phil
>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: Hangout this week?

[Werner Keil]

Have to check, if there is a JCP.next call but otherwise next Tue is fine
for me, too.


On Wed, Apr 19, 2017 at 8:30 AM, Oliver B. Fischer  wrote:

> Tuesday next week is fine for me.
>
>
> Am 18.04.17 um 23:43 schrieb P. Ottlinger:
>
> Am 18.04.2017 um 23:28 schrieb Anatole Tresch:
>>
>>> +1 for next week...
>>>
>> What about next Tuesday
>> 2017-04-25
>> 8pm Berlin time
>>
>> (I'm unavailable on Monday) ... maybe this fits for Oliver as well :-)
>>
>> n8
>> Phil
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Hangout this week?

[Werner Keil]

Hi,

Do we plan a hangout this week or will it be better next week?

Werner

Re: Hangout?

[Werner Keil]

So there was not enough for a hangout, or are we doing it another day?

Werner


On Mon, Apr 10, 2017 at 8:01 PM, Oliver B. Fischer  wrote:

> My topic for today would be only: Close the issues assigned to you for
> 0.3. This is an blocker for the release.
>
> Oliver
>
>
> Am 09.04.17 um 22:31 schrieb Anatole Tresch:
>
>> Hi guys,
>>
>> How about a hangout on Monday 20h MET (=tomorrow) ?
>>
>> J Anatole
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

Re: Hangout?

[Werner Keil]

Me, too.

On Mon, Apr 10, 2017 at 12:22 AM, Anatole Tresch  wrote:

> For me all works Mo, Tu, We...
>
> Am 09.04.2017 22:56 schrieb "P. Ottlinger" :
>
> > Am 09.04.2017 um 22:31 schrieb Anatole Tresch:
> > > How about a hangout on Monday 20h MET (=tomorrow) ?
> >
> > +1
> >
> > I'm not available on Tuesday,
> >
> > Wednesday could be possible ...
> >
> > Cheers,
> > Phil
> >
>

Re: [jira] [Commented] (TAMAYA-231) Fix developers and contributors in POMs

[Werner Keil]

No idea if that happens while a project is incubating?
John should know. However, we heard on the mailing list by 2 or 3 of them
they wanna leave.

Werner


On Thu, Apr 6, 2017 at 10:51 PM, P. Ottlinger <pottlin...@apache.org> wrote:

> Am 06.04.2017 um 22:48 schrieb Werner Keil (JIRA):
> > No, we did talk about the list of people who we think should stay
> committers. There are some Apache projects where they simply list everyone
> as "developer". Whether or not to do it that way or mention "PPMC" or "PMC"
> I guess that is secondary. Unless they are already removed, those who
> explicitely resigned should be marked "emeritus" or similar. Both in POMs
> and (especially the new) homepage.
>
> Are the people listed on the official ASF page really all emeritus?
> Did they ever provide contributions or should only thos people be listed
> that ever contributed any code/commits?
>
> Unsure which is why I wrote an email a couple of days ago.
>
> Cheers,
> Phil
>

Re: Cleaning up JIRA for 0.3

[Werner Keil]

Hi,

I simply removed the version tag from at least the Unit/HOCOM support
issues.
Especially things in the sandbox don't have to be dragged from release
number to release number. If we don't know which version it'll be ready or
it has not started, that's "backlog".

Are there any showstoppers function-wise that must be in 0.3 to be released?

Werner


On Thu, Apr 6, 2017 at 3:29 PM, Oliver B. Fischer 
wrote:

> Dear all,
>
> please update your issues in JIRA for the 0.3 release. There is a lot of
> stuff not closed or still in progress. This is a blocker for 0.3.
>
> Thank you for your support!
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>

[jira] [Updated] (TAMAYA-73) PropertyConverters for JSR 363

[Werner Keil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TAMAYA-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Keil updated TAMAYA-73:
--
Affects Version/s: (was: 0.1-incubating)
   0.2-incubating

> PropertyConverters for JSR 363
> --
>
> Key: TAMAYA-73
> URL: https://issues.apache.org/jira/browse/TAMAYA-73
> Project: Tamaya
>  Issue Type: New Feature
>  Components: Sandbox
>Affects Versions: 0.2-incubating
>    Reporter: Werner Keil
>Assignee: Werner Keil
>Priority: Minor
>  Labels: format, standard, units
>
> Similar to TypeSafe's *HOCON* 
> (https://github.com/typesafehub/config/blob/master/HOCON.md) but more 
> powerful and versatile JSR 363, the Java Units of Measurement standard allows 
> configuring anything from {{512K}} to {{32Cel}} or {{50bar}} just to give a 
> few examples.
> Projects like PCP/Parfait (https://github.com/performancecopilot/parfait) 
> demonstrate this for monitoring.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TAMAYA-234) Which JSR 363 implementations to use?

[Werner Keil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TAMAYA-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Keil updated TAMAYA-234:
---
Fix Version/s: (was: 0.3-incubating)

> Which JSR 363 implementations to use?
> -
>
> Key: TAMAYA-234
> URL: https://issues.apache.org/jira/browse/TAMAYA-234
> Project: Tamaya
>  Issue Type: Sub-task
>  Components: Sandbox
>    Reporter: Werner Keil
>    Assignee: Werner Keil
>  Labels: implementations, question, tamaya-clarifying-03, 
> tamaya-wating-response
>
> There are at least 2 major JSR 363 implementations at the moment.
> - The Reference Implementation (supports Java SE 7 and ME 8 Embedded)
> - UoM-SE (supports Java SE 8 and above)
> As long as Tamaya core supports both Java SE 7 and 8 or above, I guess I'll 
> focus on the RI for now. Where modules only use the API to communicate, it 
> should matter very little. In some cases e.g. {BigDecimal} support or 
> similar, a variation may be necessary, or implementation-specific sub-modules 
> to tamaya-uom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (TAMAYA-84) Finish asciidoc for jodatime module

[Werner Keil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TAMAYA-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Keil updated TAMAYA-84:
--
Fix Version/s: (was: 0.3-incubating)

> Finish asciidoc for jodatime module
> ---
>
> Key: TAMAYA-84
> URL: https://issues.apache.org/jira/browse/TAMAYA-84
> Project: Tamaya
>  Issue Type: Task
>  Components: Docs
>Reporter: Anatole Tresch
>  Labels: tamaya-clarifying-03, tamaya-wating-response
>
> Finish asciidoc documentation in mod_jodatime.asoc



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)