karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Papon <francois.pa...@openobject.fr>
Subject Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution
Date Thu, 13 Sep 2018 12:15:59 GMT
Hi JB,

I agree about this, we have to focus on the user friendly stuff and I
have an additional point :

  * Add a simple way to update/add properties in the default
    configuration files of the standard distribution in the assembly
    (like system.properties....)

I'm not sure this is the correct discussion but I think we also have to
work about helping user to upgrade the Karaf version of their custom
distributions.

regards,

François Papon
fpapon@apache.org

Le 13/09/2018 à 15:51, Jean-Baptiste Onofré a écrit :
> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message