For the feature generation, I have two ideas that I would like to PoC:
- use a CLI/interactive mode. For instance, if the user runs mvn karaf:feature-generate, the MOJO will ask some questions. The purpose is to "abstract" some concepts to simplify for the users. - additionally, we can imagine to have template (feature-template.xml or a yaml). The user can provide a template instead of answering questions (a kind of response file).
- this could be used for bridge the gap with bndtools as well I would like to PoC this. Regards JB On 13/09/2018 14:18, Grzegorz Grzybek wrote:
Hello Thanks JBO for the idea. True - custom distro generation isn't that intuitive as it could be. Personally I missed the flexibility, not simplicity, that's why I added <framework>custom</framework> in "[KARAF-5468] Cleaning up AssemblyMojo, Profiles and profile Builder". Without it, the implied value for "framework" property was "framework" or "static-framework" depending on whether you had dependency on mvn:org.apache.karaf.features/framework/VERSION/kar or mvn:org.apache.karaf.features/static/VERSION/kar in your POM. The discovered "framework" property was added as "startup feature" which was very confusing (mixing "framework" and "feature" concepts). I can't tell much about improvements for karaf-maven-plugin:features-generate-descriptor, because I always preferred manual creation of feature XMLs. However having dependency on existing karaf distro ("standard" apache-karaf or apache-karaf-minimal) is good idea! karaf-maven-plugin:assembly could search zip or tar.gz or tgz kind of dependencies (with "provided" or any other scope) and: - unpack it - check etc/profile.cfg etc/profile.cfg is (since 4.2.0) nicely written as (official apache-karaf-minimal distro): # # Profile generated by Karaf Assembly Builder # # Parent profiles attribute.parents = generated-startup generated-boot generated-installed # Attributes attribute.overlay = true # Feature XML repositories repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features = mvn:org.apache.karaf.features/framework/4.2.0/xml/features repository.mvn\:org.apache.karaf.features/standard/4.2.0/xml/features = mvn:org.apache.karaf.features/standard/4.2.0/xml/features repository.mvn\:org.apache.karaf.features/spring/4.2.0/xml/features = mvn:org.apache.karaf.features/spring/4.2.0/xml/features # Features feature.framework = framework feature.jaas = jaas feature.shell = shell feature.feature = feature feature.ssh = ssh feature.bundle = bundle feature.config = config feature.log = log However, with complex distros it can look like this (my distro) - see all the blacklisted items and even special configuration options - these are all generated from pom.xml: # # Profile generated by Karaf Assembly Builder # # Parent profiles attribute.parents = generated-startup generated-boot generated-installed # Attributes attribute.overlay = true # Feature XML repositories repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features = mvn:org.apache.karaf.features/framework/4.2.0/xml/features ... # Features feature.framework = framework feature.patch-management = patch-management ... feature.pax-jms-config = pax-jms-config feature.pax-jms-pool-narayana = pax-jms-pool-narayana feature.pax-jms-pool-transx = pax-jms-pool-transx # Bundles ... bundle.mvn\:org.bouncycastle/bcprov-jdk15on/1.60 = mvn:org.bouncycastle/bcprov-jdk15on/1.60 bundle.mvn\:org.bouncycastle/bcpkix-jdk15on/1.60 = mvn:org.bouncycastle/bcpkix-jdk15on/1.60 # Configuration properties for etc/config.properties config.karaf.delay.console = true # Blacklisted repositories blacklisted.repository.mvn\:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features = mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features ... # Blacklisted features blacklisted.feature.httplite = httplite blacklisted.feature.jetty/[8,9) = jetty/[8,9) blacklisted.feature.pax-*jetty* = pax-*jetty* blacklisted.feature.cxf-*-jetty = cxf-*-jetty ... # Blacklisted bundles blacklisted.bundle.mvn\:org.ops4j.pax.cdi/pax-cdi-jetty-weld = mvn:org.ops4j.pax.cdi/pax-cdi-jetty-weld This etc/profile.cfg can be treated simply as it was added in karaf-maven-plugin:assembly configuration itself! <configuration> <profilesUris> <uri>path/to/profile.cfg</uri> </profilesUris> </configuration> best regards Grzegorz Grzybek czw., 13 wrz 2018 o 13:51 Jean-Baptiste Onofré <j...@nanthrax.net> napisał(a):Hi guys, Recently, we received a lot of questions around how to create Karaf custom distribution based on karaf-maven-plugin, and how to use the static profile to create "standalone/static" distribution. If the plugin works fine, it's not easy to understand some "details", like the dependency scope impact, or providing the set of default features repos and features. I already helped users (in private communication) to fix their custom distributions. Obviously, we should simplify the way of creating custom distribution, especially with the new tooling & feature we now provide around Docker. I would like to propose the following: 1. Set the default behavior of the assembly goal to create a custom distribution based on standard. For the user, instead of providing (again) all framework, standard, enterprise features repos and all standard boot features (shell, ...), it will just specify the tar.gz/zip base and his own features repo/repos (or the goal will use the same version of the goal plugin itself). All the rest will be done by the plugin for him. Use the karaf packaging as default to define this. At the end of the day, the user pom.xml will look like: <project> <groupId>foo</groupId> <artifactId>bar</artifactId> <version>1.0-SNAPSHOT</version> <packaging>karaf</packaging> <dependencies> <dependency> <groupId>org.apache.karaf</groupId> <artifactId>apache-karaf</artifactId> <version>4.2.1</version> <type>tar.gz</type> </dependency> <dependency> <groupId>foo</groupId> <artifactId>my</artifactId> <version>1.0-SNAPSHOT</version> <classifier>features</classifier> <type>xml</type> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.karaf.tooling</groupId> <artifactId>karaf-maven-plugin</artifactId> <extensions>true</extensions> <inherited>true</inherited> <configuration> <bootFeatures> <feature>my</feature> </bootFeatures> <installedFeatures> <feature>my-other</feature> </installedFeatures> </configuration> </plugin> </plugins> </build> </project> The idea is to automatically execute install-kar + assembly for the karaf packaging and let the user focus on its own resources (features, config, ...) just providing the base Karaf archive. The user will be able to use src/main/resources to provide any files in etc, bin, or whatever in the resulting custom distribution. 2. Improve a bit the features XML generation If the custom distribution is the highest priority, just after the improvements on this area, I would like to improve the way of creating features XML. Now, to be honest, almost all of us write features repos XML by hand. It gives us the maximum of flexibility. However, on the other hand, the features XML and code contain should be sync. I would like to improve the generate features MOJO, however leveraging most of all functionalities around features (prerequisites, dependency flag, inner features, ...). I have to dig a little bit around that, but if you want some ideas already, please let me know. Thoughts ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
