Oops. That should read:
"Commonly then I can keep a standard file called configuration.cfg in the
filtered-resources..." Of course you can call it anything you like, the
point is just that if it is always the same name the features install
becomes much easier especially when tired or harried (and really is there
any other mode of operation for a developer?)
On Thu, Sep 15, 2016 at 9:50 AM, Brad Johnson <brad.john...@mediadriver.com>
wrote:
> 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.
>>
>
>
