For the template, we can share some templates on the Karaf website like
the feature XSD files ?
For example, a template to create a api rest feature based on Apache CXF.
regards,
François Papon
fpa...@apache.org
Le 13/09/2018 à 19:18, Jean-Baptiste Onofré a écrit :
> 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
>>>
>>
