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
>
