More succinctly:
parent.batch.cfg
children
parent.batch.dev.cfg
parent.batch.test.cfg
parent.batch.production.cfg
childeren
com.my.batch.transaction.cfg
com.my.batch.accountupdates.cfg
Would result in these files in the configuration bundle:
com.my.batch.transaction.dev.cfg
com.my.batch.accountupdates.dev.cfg
test and dev.
The features file would then be:
<feature name="dev.someproject" version="${project.version}">
<configfile finalname="/etc/com.my.batch.transactions.cfg"
override="true">mvn:com.someproject/config/${project.
version}/cfg/com.my.batch.transactions.dev</configfile>
<configfile finalname="/etc/com.my.batch.accountupdates.cfg"
override="true">mvn:com.someproject/config/${project.
version}/cfg/com.my.batch.accountupdates.dev</configfile>
...then call the feature to install the bundles...
I'd then have a compact way of specify shared properties in parents,
compiled into bundle and then installed via feature.
On Fri, Jul 8, 2016 at 9:22 AM, Brad Johnson <[email protected]>
wrote:
> After getting into these discussions I started thinking that perhaps I'd
> move all the configuration files into one bundle and install them from
> features file that way. I could have dev/test/prod cfg files in that same
> bundle.
>
> Using a combination of filtered resources and some other mechanics then I
> can perhaps come up with a way so that
>
> com.my.batch.transaction.cfg
> com.my.batch.accountupdates.cfg
>
> have a com.my.batch.parent.cfg and during Maven build it is read into and
> made part of both the transaction and account updates.cfg files. Those are
> then put into the configuration bundle. When that configuration bundle is
> installed the PIDs/properties match the bundles looking for them but
> contain the common information as already been flattened into them.
>
> That configuration bundle could also have test/dev/production cfg files
> and the features file could permit installing test, dev or production the
> only difference being which set of configuration files they installed
> before installing the bundles themselves.
>
>
> On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <[email protected]
> > wrote:
>
>> Here's a small example. The two batch processes do very different things
>> yet share some common configuration information pertaining to directories,
>> ftp and service endpoints. That configuration information obviously also
>> varies between dev, test, and production. This is one small part of the
>> project. The connector project is already a crosscutting concern that
>> keeps its connection information separated from all the other business
>> processes/services that use it. Some of the properties have queue names
>> (SEDA or JMS) that are shared between bundles and use runtime substitution
>> in Camel. But duplicating configuration information between the bundles
>> and hand massaging it is error prone and makes refactoring a pain.
>>
>> <feature name="someproject" version="${project.version}">
>>
>> <configfile finalname="/etc/com.litle.cfg"
>> override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
>> <configfile finalname="/etc/com.my.batch.transactions.cfg"
>> override="false">mvn:
>> com.my/batch.transactions/${project.version}/cfg/configuration
>> <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration>
>> </configfile>
>> <configfile finalname="/etc/com.my.batch.accountupdates.cfg"
>> override="false">mvn:
>> com.my/batch.accountupdates/${project.version}/cfg/configuration
>> <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration>
>> </configfile>
>> <feature>camel-core</feature>
>> <feature>camel-blueprint</feature>
>> snip
>>
>> And some route like:
>>
>> <to
>> uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
>> />
>>
>> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <
>> [email protected]> wrote:
>>
>>> Can you give some examples of typical config properties that need to be
>>> shared between these bundles. Maybe they lead to an idea for a different
>>> design.
>>>
>>> Christian
>>>
>>> On 08.07.2016 15:09, Brad Johnson wrote:
>>>
>>>> Christian,
>>>>
>>>> Thanks for the feedback. I'm actually looking for a bit more robust
>>>> solution. Just the one small project I'm working on now has 12 business
>>>> processes with a number of OSGi services that provide cross-cutting
>>>> concerns. In this case they are service like credit card authorization,
>>>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>>>> to route them. But each of those business processes use OSGi services that
>>>> might call out to banks, PayPal, analytics services, etc. Keeping these
>>>> nicely segregated in their own bundles makes them very testable for the
>>>> routing, data transformation to/from canonical form, etc. But
>>>> configuration management is a bit of a pain because of the PID pinning. I
>>>> use update strategy reload on the bundles so that configurations can be
>>>> changed in different environments.
>>>>
>>>> Until now I've kept my configuration files in each bundle and pop them
>>>> out using the features install mechanism. But I'm rethinking that based on
>>>> these discussions. I don't know if the Maven properties plugin would do
>>>> what I'm thinking about but it might be a platform to develop such a
>>>> plugin. In this case I'd have a separate configuration bundle with my PID
>>>> cfgs in them and N levels of parent cfg files. The properties would just
>>>> be rolled up and written out into PID specific cfg files. If I define a
>>>> port or directory in a parent then all the children would inherit or
>>>> override that property. That would permit the use of profiles for dev,
>>>> test and production as well. Modifying any of the cfg files and then
>>>> putting that through Jenkins would result in a nice configuration bundle
>>>> that once reinstalled would trigger a reload. In the end the port or
>>>> directory or endpoint configuration information would be duplicated in each
>>>> cfg but it wouldn't require hand massaging of each cfg to change.
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>
