karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution
Date Fri, 14 Sep 2018 05:13:25 GMT
yep, that  would be more neat!
-------------
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



> On Sep 14, 2018, at 12:03 PM, Francois Papon <francois.papon@openobject.fr> wrote:
> 
> Hi Freeman,
> 
> Yes I know but we already have some user in the mailing asking for that.
> 
> I was thinking about including the configuration of property-edits
> directly in the karaf-maven-plugin configuration.
> 
> Thoughts ?
> 
> Regards,
> 
> François Papon
> fpapon@apache.org
> 
> Le 14/09/2018 à 05:39, Freeman Fang a écrit :
>> Hi François,
>> 
>> I believe we can already do it to update/add/remove properties in configuration files.
>> 
>> You just need a src/main/karaf/assembly-property-edits.xml like
>> 
>> <property-edits xmlns="http://karaf.apache.org/tools/property-edits/1.0.0">
>>         <edits>
>>          <edit>
>>            <file>config.properties</file>
>>            <operation>put</operation>
>>            <key>karaf.framework</key>
>>            <value>equinox</value>
>>          </edit>
>>          <edit>
>>            <file>config.properties</file>
>>            <operation>extend</operation>
>>            <key>org.osgi.framework.system.capabilities</key>
>>            <value>my-magic-capability</value>
>>          </edit>
>>          <edit>
>>            <file>config.properties</file>
>>            <operation>remove</operation>
>>            <key>org.apache.karaf.security.providers</key>
>>          </edit>
>> 
>> 
>>        </edits>
>>      </property-edits>
>> 
>> You can get more details from [1]&[2]
>> [1]https://issues.apache.org/jira/browse/KARAF-3982
>> [2]https://issues.apache.org/jira/browse/KARAF-5868
>> Best Regards
>> 
>> -------------
>> Freeman(Yue) Fang
>> 
>> Red Hat, Inc. 
>> FuseSource is now part of Red Hat
>> 
>> 
>> 
>>> On Sep 13, 2018, at 8:15 PM, Francois Papon <francois.papon@openobject.fr>
wrote:
>>> 
>>> 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