Hi everyone, Just created the repository as mentionned earlier.
Here it is: https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git I will try to add some basic doc module and work on tests after. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 28 oct. 2019 à 18:47, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit : > It sounds good. +1. > > Regards > JB > On 28/10/2019 18:07, Romain Manni-Bucau wrote: > > Hi everyone, > > I'm planning to create the repo tomorrow and try to get some doc for > wednesday night. > Is it ok for everyone? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le dim. 27 oct. 2019 à 18:04, Romain Manni-Bucau <rmannibu...@gmail.com> > a écrit : > >> Hi Guillaume, >> >> Yes and no, First iteration I'd like to: >> >> 1. Enable to build a command graal line and execute it through a mojo (to >> have an e2e case) >> 2. Provide a simple API to let the user register classes (my current >> version is very specific to a few frameworks so i must abstract it but idea >> is to let some classes be found based on annotations or parent for ex and >> register them). Guess it will not use a feature but more a preprocessing >> phase generating a valid reflection.json (potentially resources.json and >> dynamicproxy.json in terms of design). Then we can run 1. with this config. >> In my case - job framework - i can find all the classes i need reflection >> on so i just list them all (it is close to Arc I guess?). >> 3. (optional for first import) provide some library integrations >> (substitutions and/or features, no arthur abstraction) to help with some >> common libraries. I needed some for johnzon so it can be one integration >> module for ex. >> >> Hope it makes sense. >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Book >> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >> >> >> Le dim. 27 oct. 2019 à 17:37, Guillaume Nodet <gno...@apache.org> a >> écrit : >> >>> >>> >>> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <rmannibu...@gmail.com> >>> a écrit : >>> >>>> >>>> >>>> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gno...@apache.org> a >>>> écrit : >>>> >>>>> >>>>> >>>>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau < >>>>> rmannibu...@gmail.com> a écrit : >>>>> >>>>>> >>>>>> >>>>>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gno...@apache.org> a >>>>>> écrit : >>>>>> >>>>>>> >>>>>>> >>>>>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau < >>>>>>> rmannibu...@gmail.com> a écrit : >>>>>>> >>>>>>>> Hi Raymond, >>>>>>>> >>>>>>>> What do you mean y "taking us down"? >>>>>>>> To give some background, I have some use case where a k8s >>>>>>>> orchestrator + native java run would be a good option compared to a >>>>>>>> long >>>>>>>> running program (see it as lambda like archi). >>>>>>>> I did some basic tooling - guess it is the same than you more or >>>>>>>> less - and just would like a home for now. >>>>>>>> Now I agree graal is not for all apps, it is not even possible to >>>>>>>> compile a jdbc driver today - yes quarkus faked it ;). >>>>>>>> >>>>>>> >>>>>>> I've been working on camel-quarkus recently and we do have >>>>>>> integration tests that use JDBC and that are compiled to native mode. >>>>>>> Not sure what you mean when you say it's not possible to compile a >>>>>>> jdbc driver. I'd be interested in understanding what you mean here. >>>>>>> >>>>>> >>>>>> It is going a bit off topic and guess if arthur has no strong >>>>>> objection we'll discuss it a bit in other threads but long story short,if >>>>>> you dont replace a bunch of code the driver will not work. Quarkus h2 >>>>>> kept >>>>>> only client mode to simplify part of it. H2 by itself works in client, >>>>>> file >>>>>> and mem if you do the reflection work but then if the jdbc pool or app >>>>>> uses >>>>>> DriverManager, most codepath will require to load all the driver at build >>>>>> time and often end up on some blocker you need to cut like natives or >>>>>> unsupported api. I got the same experience with derby. It is not the >>>>>> driver >>>>>> by itself but the SPI + common driver/jdbc usages which make it often >>>>>> hard >>>>>> to use without forking part of the libs. >>>>>> Fun fact is hikari is broken by that but not tomcat-jdbc cause their >>>>>> load(driver)/DriverManager chain is opposed. >>>>>> >>>>> >>>>> That's nothing related to Quarkus but just the effect of native code >>>>> compilation I think. >>>>> The limitation comes from compiling to native: the whole world has to >>>>> be known at compile time, so dynamic class loading is not feasible. >>>>> Loading a "new" jdbc driver dynamically will never work in native mode. >>>>> However, the SPIs (be it xml, jaxb, jdbc or whatever) usually rely on >>>>> loading a properties file and instantiating the class name found in it. >>>>> This part can be made to work in native mode, but it has to be known at >>>>> build time and taken care of. In this case, one needs to instruct the >>>>> native compiler about the properties file (so that it's included in the >>>>> native binary) and about the reflection needed for the driver class (so >>>>> that it can be instantiated using its class name). >>>>> So the short answer is : if you try to take any complex application >>>>> and compile it to native mode, it won't work as is. And that's the reason >>>>> why all libraries need to be "validated" before being usable in a native >>>>> compilation : each limitation of the graal vm needs to be worked around, >>>>> things explicited, reflection known before hand, etc... Quarkus, amongst >>>>> other things, helps doing that and provides a set of "validated" >>>>> components. >>>>> >>>> >>>> I didnt say quarkus was guilty, point was that even the very high >>>> investment ibm/redhat did, h2 is not supported by their stack except in >>>> client mode which is not a simplicity sign. Sorry if it was ambiguous, my >>>> point was not to blame but to highlight I agreee with Ray we must not >>>> emphasis the simplicity of graal but only enable the build to be less hard. >>>> >>> >>> Ok. >>> >>> What do you have in mind exactly ? At first glance, it seems you want to >>> scan and register all classes for reflection and all resources to be >>> included ? >>> If that's what you have mind, I think it can cause some problems: the >>> graal vm heavily rely on dead code elimination (because the world is known >>> and it can analyse all the code paths). I fear that registering all >>> classes for full reflection may have a very bad effect of actually killing >>> any dead code elimination, because all methods / classes will have to be >>> present in the compiled code. Subsequent effects will be a bigger native >>> code size and longer native code compilation... >>> Or do you have something smarter in mind ? >>> >>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> Romain >>>>>> >>>>>> >>>>>> >>>>>>> Guillaume >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>>>>> >>>>>>>> >>>>>>>> Le ven. 25 oct. 2019 à 16:02, Raymond Auge < >>>>>>>> raymond.a...@liferay.com> a écrit : >>>>>>>> >>>>>>>>> I'm not vehemently opposed as I have done my own graal salivating >>>>>>>>> and not that I think anyone would care much even if I was completely >>>>>>>>> opposed; but I will caution that this whole graal thing is a >>>>>>>>> dangerous path >>>>>>>>> that Oracle (and seemingly Redhat is just as happy to do it) are >>>>>>>>> taking us >>>>>>>>> all down. >>>>>>>>> >>>>>>>>> Anyway +0.5 >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> - Ray >>>>>>>>> >>>>>>>>> On Fri, Oct 25, 2019 at 2:21 PM Francois Papon < >>>>>>>>> francois.pa...@openobject.fr> wrote: >>>>>>>>> >>>>>>>>>> Hi Romain! >>>>>>>>>> >>>>>>>>>> I think it's a great idea, it make sense to have tooling around >>>>>>>>>> graalvm. >>>>>>>>>> >>>>>>>>>> I will be more than happy to contribute ;) >>>>>>>>>> >>>>>>>>>> "arthur" looks good to me :) >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> >>>>>>>>>> Françoisfpa...@apache.org >>>>>>>>>> >>>>>>>>>> Le 25/10/2019 à 09:00, Romain Manni-Bucau a écrit : >>>>>>>>>> >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> Wonder if we want to create a small project to simplify graalvm >>>>>>>>>> builds? >>>>>>>>>> What I have in mind is basically a kind of main (+ maven wrapper) >>>>>>>>>> which enables to use scanning at build time to prepare a binary, do >>>>>>>>>> the >>>>>>>>>> right RuntimeReflection.register and set the right configuration >>>>>>>>>> for proxies, resources etc. >>>>>>>>>> It would be a companion of XBean finder - which is a perfect fit >>>>>>>>>> for this phase - but likely outside of XBean since the project will >>>>>>>>>> likely >>>>>>>>>> require to use docker for tests - since we go native, otherwise we >>>>>>>>>> wouldn't >>>>>>>>>> build portably - and creates its own ecosystem. >>>>>>>>>> >>>>>>>>>> Side note: if we go with it, I'm tempted to call it "arthur", if >>>>>>>>>> you +1 the idea don't hesitate to also comment on the name >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>>> (@rotty3000) >>>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>>>>>>> (@Liferay) >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> ------------------------ >>>>> Guillaume Nodet >>>>> >>>>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> >>>
