karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution
Date Thu, 13 Sep 2018 13:53:38 GMT
Thanks for your feedback Greg.

I started a new local branch with "new" karaf-maven-plugin custom
distribution approach. This branch also contains an example.

I will create a corresponding PR and an update on the mailing list to be
able to discuss all together.

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é <jb@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message