Thanks for your feedback David, nice idea about jlink, I have to investigate a little about it, but definitely interesting.
Regards JB On 11/02/2019 12:52, David Daniel wrote: > I really like the idea of the static build and features in code. I think > the jdk is making great strides in getting java running well on docker > java 9 jlink for small images that can be copied and spun up quickly > java 10 defaults improvements https://aboullaite.me/docker-java-10/ > portola for running java on musl (alpine without glibc) > https://openjdk.java.net/projects/portola/ > loom is coming for not spinning off a ton of threads > If at all possible I would love to be able to build a minimal karaf > distribution with jlink from java module files that were generated from the > karaf resolver. I think this might be a little much though and don't even > know if it is possible. Just something that might be able to be looked at > while the code is being written. > > David > > > On Mon, Feb 11, 2019 at 1:57 AM Jean-Baptiste Onofré <[email protected]> > wrote: > >> Hi guys, >> >> As we now have released Karaf runtime 4.2.3 and started 4.3.x, I think >> it's time to discuss and move forward "concretely" about the "kloud" >> (Karaf for the Cloud) initiative. >> >> I think the first approach is focused on the developers and devops. I >> created the following Jira: >> >> https://issues.apache.org/jira/browse/KARAF-5923 >> https://issues.apache.org/jira/browse/KARAF-6148 >> https://issues.apache.org/jira/browse/KARAF-6149 >> https://issues.apache.org/jira/browse/KARAF-6150 >> >> The idea is really to simplify the features generation and distribution >> packaging. >> >> For the features generation, I'm thinking on annotations directly in the >> code (in package-info.java for instance) describing the features needed >> by the application. The annotations scanner could then create the >> features XML using the code itself and the annotations. That would allow >> us to not relay on Maven and be able to support CLI/Gradle/Maven. In the >> case where the user uses Maven, we could better leverage Maven to get >> some details. The idea is to especially easily create features XML to >> build "static" runtime (that make sense for the cloud). >> >> After the features XML generation, we should have a easier way to build >> a distribution. We also have to provide multiple "packaging output" like >> archives (zip/tar.gz), uber jar (embedding karaf and user application), >> docker image, openimage, kubernetes meta, ... >> The idea is to have a ready to go packaging for the cloud. >> >> For the cloud perspective, the distribution should be >> "immutable/static". Currently, the resolver we have is great for >> "dynamic" deployment but could be painful for static one (dealing with >> refresh, multiple versions resolution, etc). >> I'm proposing to create kind of "static" resolver >> (https://issues.apache.org/jira/browse/KARAF-6147) directly taking boot >> features and installing straight forward what's defined in the features. >> It should result with a more "predictable" behavior, really helpful from >> a cloud perspective. >> >> Finally, I created some Jira about general improvements for the cloud >> and docker: >> >> https://issues.apache.org/jira/browse/KARAF-6111 >> https://issues.apache.org/jira/browse/KARAF-4609 >> >> I think you got the overall idea: dramatically simplify creation of >> distribution packaging karaf with user application (for developer), >> simplify the packaging outputs and bootstrapping on cloud (for devops). >> >> If you think it could be helpful to have a doc on confluence about that, >> please let me know I will create it. >> >> We all know that Karaf is an amazing runtime. To convince more and more >> users and give a new dimension to Karaf, I really think that the "kloud >> initiative" is a must have. We will have a runtime that can address both >> static and dynamic bootstrapping approach, one runtime for multiple >> services or one runtime per service, etc. >> >> Thoughts ? >> >> Regards >> JB >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
