On Wed, Jul 20, 2016 at 11:12 AM, Mark Struberg <[email protected]> wrote:
> > Portability is a difficult Thing. We will not get a truely portable > > solution as Java EE also is not as Long as we have a portable > configuration > > Definition for administrative resources as well, which Oracle (UNTIL NOW) > > actively fights against. > > We know pretty exactly how a truly portable solution works. The DeltaSpike > solution works really well in that regard. > > And No, Oracle doesn’t fight against a configuration JSR if done right. > Never did. > There was a short period when Oracle fought against themselves and > everything else went black becasue of that. > But I seriously hope those times are over now. > > Nobody knows till at least JavaOne or probably early next year. Java EE despite the community being able to act in parallel won't be fully picked up by Oracle if they're still working on Java SE 9. So probably a year from now till we see some sustainable activity in those JSRs and projects that are not shut down before. Oracle is not alone to blame. It took too much on its plate and now realizes they can't all do it alone. Others had to learn this in a similar way, and looking at Microsoft actively evangelizing many Apache projects now at conferences and roadshows (or what they do with Angular) or having open sourced major parts of .NET they seem to be in a better shape and position than Oracle. At least for now. Maybe the initial founder still on the top position pulling all the strings is part of the problem. Microsoft had at least 2 CEO changes since Gates, Oracle is still run by its original founder who started it around the same time. And there are new companies created as spin-offs from popular Open Source projects all the time. Spring, Apache or Docker, you name them. Not to forget many Social and Web giants from Amazon to Twitter. Unfortunately the likes of Tomitribe or especially Paraya seem to have a hard time contributing back, at least neither of them were able to play a Spec Lead role so far. Paraya AFAIK isn't even a JCP member, so they "take from the Fish pond without contributing back" at the moment. While especially Red Hat actively contributes to CDI or Bean Validation just to name the two specs it leads and started. > > Talking about a minimal API but including the source based Approach for > me > > doent match. > > Think about CDI or Spring without any CDI-Extensions or Spring bootstrap > changes. > That would have made it impossible to implement 80% of all the code that > happened with those frameworks. > > Also I’m not quite sure if it’s a wise idea to push changes to the ASF > cannonical git repo despite the fact that we are _still_ discussing things > and the majority is opposed such changes. > The same thing happend a year ago and it starts to happen again. > Don’t get me wrong, I like to see code to play with. But if you didn’t yet > get it we cannot easily get rid of branches once they are in the cannonical > repo. They immediately get mirrored downstream to dozen repos. So please > use github for playground activities in the future. > > With JSRs like 310 (at least before it was integrated into OpenJDK, no idea who contributes now, must be mostly Oracle i18n people now) 354 or 363 that "playground" were private forks or branches of relevant parts of the API. What was agreed to be a good idea got merged back to the main master branch, other proposals became dead ends. There are at least branches like "tamaya.next" already in Tamaya. Whether you fork it in GitHub or directly in the Apache Git repo does not matter, but only the ASF repo seems to have write access, so merging it back may not work in GitHub or do you have other experience? Henrik even proposed 2 PRs but they were probably overlooked in GitHub or may not work there. With those mirrors at least I am not aware e.g. being able to push things back to projects like Eclipse UOMo and others (Eclipse uses a similar mirror) As long as you refrain from foolish things like calling it "javax.something" before a true JSR exists on jcp.org and you're an EG member listed there (the PMO and Oracle Legal would also act against anybody trying to recreate "javax.enterprise" like CDI in their own private Git repo especially if they're not even EG members) of course straw man examples in everybody's own private backyard seem OK, too, but it won't help Tamaya unless patterns found to be good are contributed back there, too. The "PMC" / poddling of Tamaya may be slightly bigger than that of DeviceMap even when 2 or 3 former contributors were still active. We faced a serious challenge when former PMC chair Reza decided all by himself the XML based device data suddenly had to be converted to JSON (doing so with his own tool or converter, he never contributed it back, only the results) without a clue or strategy how 2 parallel device data streams should be maintained if one already puts the open Apache community to a serious test compared to closed source competitors. The result was he eventually left Apache completely and put his fork here https://github.com/TextGlass/device. See for yourself, nobody cares, he's the only follower of the repos, nobody even forked it and it was last updated a year ago. A pet project that died. And while the idea of using JSON is not bad, with the remaining PMC members DeviceMap just could not handle 2 parallel data repositories right now. The old XML one is still downloaded quite a bit. I believe Apache SonaType lost some download stats when I last checked (it had decent figures for every project also DeltaSpike, Pluto and others before) so it is not the most active Apache project, never was, but it's far from dead as long as people still download and use the device data or client software. Ok enough "wisdom" from other projects. Nobody is prevented from trying out things, but keep in mind, Tamaya isn't even where DeviceMap is now meaning out of the Incubator. If everyone just does "their thing" in private GitHub repositories, it won't graduate due to lack of visible activity for board reports. Cheers, Werner > txs and LieGrue, > strub > > > > Am 20.07.2016 um 09:36 schrieb Anatole Tresch <[email protected]>: > > > > Portability is a difficult Thing. We will not get a truely portable > > solution as Java EE also is not as Long as we have a portable > configuration > > Definition for administrative resources as well, which Oracle (UNTIL NOW) > > actively fights against. So a common API unifying approaches in SE and EE > > for me brings what we can do as of now. > > Talking about a minimal API but including the source based Approach for > me > > doent match. This does not mean we cannot provide some Default > > functionality: E.g. if we have Configuration as the main delegate API, we > > can simply define that by Default configuration is built up using: > > - env props > > - System props > > - properties read from the CP, e.g. javaconfiguration.properties > > - properties read from a file/Directory. > > > > This "Default" mechanism is enough in most cases. And exchanging it with > a > > property source based one (or whatever) is trivial. Additionally non > > constraining users may also be good for the Overall ecosystem since it > > gives space to the community to think on how configuration can be > > organized. I also have alternate, e.g. event-driven ideas, so property > > sources must not be everything and I actually dont want them to see as > > pafrt of the API, but a propertysources module (BTW: I am currentl > exactly > > experimenting with such an Approach, will perhaps commit it this evening > to > > the tamaya-next branch. > > On this branch I also factored out functionality for serviceloading and > > adapting configuration, using the ladder to Support type safew > > configuration based on modules/Adapters ;) > > > > J A > > > > 2016-07-19 22:20 GMT+02:00 Mark Struberg <[email protected]>: > > > >> > >>> Am 19.07.2016 um 17:45 schrieb Anatole Tresch <[email protected]>: > >>> > >>> Not providing any kind of mechanism, but > >>> the API also makes us less vunerable to discussions about how > >> configuration > >>> should be organized, which ultimately is the main issue, why > >> standardizing > >>> it is so difficult. So from a political perspective it may be an > >> advantage > >>> NOT to define the mechanisms behind, but only provide the main > mechanism > >> to > >>> access it, the API. > >> > >> I see the point, but I fear it falls a bit too short. > >> Think about JSR-330 (atinject). It only provides the ‚consumer‘ API. > >> Is it usable? No, it _always_ needs another spec to be usable. Be it > CDI, > >> Guice or Spring. > >> It is *absolutely* impossible to provide a portable solution based on > >> atinject alone. > >> It is just the least common denominator of a few frameworks. > >> > >> Do we like to do that? > >> If so, how does a user build it’s applications in a *portable* way? > >> Without any SPI or very simple default ways to configure your app this > is > >> imo impossible. > >> That’s the reason why I really would love to see the SPI as part of > such a > >> spec. > >> > >> LieGrue, > >> strub > >> > >> > > > > > > -- > > *Anatole Tresch* > > PPMC Member Apache Tamaya > > JCP Star Spec Lead > > *Switzerland, Europe Zurich, GMT+1* > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > > *Twitter: @atsticks, @tamayaconf* > >
