Hello everyone, I pushed a first version online: https://geronimo.apache.org/arthur/index.html. The most interesting one is likely the maven one today: https://geronimo.apache.org/arthur/maven.html.
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 mar. 29 oct. 2019 à 10:02, Francois Papon <francois.pa...@openobject.fr> a écrit : > Nice! > > Thanks Romain! > > regards, > > Françoisfpa...@apache.org > > Le 29/10/2019 à 08:52, Romain Manni-Bucau a écrit : > > 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 >>>> >>>>
