Owain,
Cool. If you made that header change I think you'll see what you are
after. Incidentally I'll commonly use the groupId and artifactId as my PID
name. Commonly then I can keep a standard file called config.cfg in the
filtered-resources of the project and in the features file have it install
the config.cfg as groupId.artifactId.cfg. You'll need this in your parent
or even child POM.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<skipAttach>${skip.attachment}</skipAttach>
<artifacts>
<artifact>
<file>src/main/filtered-resources/configuration.cfg</file>
<type>cfg</type>
<classifier>configuration</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
Note the skip.attachment flag. By default I'll set that to true so the
child has to explicitly set it to false in order to get the
filtered-resource attached.
In the features file you can add a line like this:
<configfile finalname="/etc/com.foo.bar.cfg"
override="false">mvn:com.foo/bar/${project.version}/cfg/configuration</configfile>
That then installs the standard configuration.cfg file contained in your
project into the etc directory with the same name as the groupId and
artifcatId. It makes it easy to remember what the PID is then as well
since you are telling to get the cfg out of the com.foo/bar Maven repo and
so that should be the name of your cfg file as long as your PID in the
blueprint properties matches that.
That works well for largish projects but if you aren't using features files
or if that seems too convoluted then just do it some other way. The one
advantage is that you always know the name of the configuration.cfg file
you want to get from your bundle and all your projects are fairly
standardized then - more convention over configuration.
On Thu, Sep 15, 2016 at 4:27 AM, owain <owain@integration.technology> wrote:
> Thanks for the two responses. The blog post is very comprehensive. I have
> updated blueprint-cm-1.1.0 and have added the update strategy to reload.
>
> Yes the persistent-id does not have cfg on the end, just the filename.
> (also the persistent id cannot have a - in it ends up being a Java method
> name, another gotcha!)
>
> I have yet to test the override but will report back.
>
> Thanks again.
>
> O.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Fuse-Blueprint-properties-override-tp5787541p5787590.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
