I kind of like the fact that it is generating the XML and not interpreting
the annotations at runtime.  At least if there are problems you can crack
open the jar file and look at the generated XML to see what's going on.

When I mentioned the configuration I was thinking about the Maven plugin
that does this and feature that does what follows:
*Plugin*
<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>
                            <artifacts>
                                <artifact>

<file>src/main/resources/configuration.cfg</file>
                                    <type>cfg</type>
                                    <classifier>configuration</classifier>
                                </artifact>
                            </artifacts>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

*Feature*
<configfile
finalname="/etc/${project.groupId}.invoice.${project.version}.cfg">mvn:${project.groupId}/invoices/${project.version}/cfg/configuration</configfile>

Obviously one would have to put up some sort of metadata tag in the bundle
so it would know the associated cfg file.  But with my deep ignorance of
SCR I don't know if that would work or not.



On Fri, Jan 29, 2016 at 2:05 PM, Quinn Stevenson [via Camel] <
[email protected]> wrote:

> We haven’t found a plugin to generate the CFG files (property files in our
> case) - they’re created by hand.  Luckily they don’t change much - that’s
> why the rename thing for semantic versioning will be a royal pain.
>
> I sympathize with the issues you’re having with CamelBlueprintTestSupport
> - until recently, it’s been very problematic with the race conditions.
> Since the last set of fixes went in, I haven’t had any issues.  Note that
> the Camel archetype for blueprint used to generate a bad configuration in
> the POM that caused me a lot of grief.  I submitted a PR and it was merged
> into 2.17-SNAPSHOT, but you could use that and then change the Camel
> version in the POM and get a good start.
>
> That said, by using the Java RouteBuilders, we can test our routes using
> CamelTestSupport and get around all those CamelBlueprintTestSupport
> issues.  We’re working on some integration tests as well using Pax Exam, so
> we’ll only be using CamelBlueprintTestSupport during development - we won’t
> care so much if those test fail in our CI builds.
>
> The one thing about camel-scr I don’t particularly like is all the
> annotations - it really muddies-up the code.  They are only used by the
> maven-scr-plugin to generate a beans.xml file.  I think I’d rather build
> this file using maven filters or something.  Also, watch out for the
> version of the maven-scr-plugin you use - I don’t remember which version it
> was, but one of the newer ones didn’t work (a beans.xml file wasn’t
> generated).
>
>
> > On Jan 29, 2016, at 12:55 PM, Ranx <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5777015&i=0>> wrote:
> >
> > Thanks for the insights.  It sounds as if the cfg files would need a
> form of
> > semantic versioning then like bundles use. Obviously my insights are
> > limited.  Do you create your configuration files via the maven plugin
> and
> > install them in etc with a feature?  That might obviate some of the
> pain.
> >
> > I'd have to look a bit closer at it.  I do like what I see of it. I get
> > tired of XML fingerfehlers causing CBTS to hang with the rather nebulous
> > "Gave up waiting for CamelContext" errors.  I'm also an old Java hack so
> > prefer it anyway.
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777014.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777015.html
> To unsubscribe from Camel SCR, click here
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5776954&code=YnJhZC5qb2huc29uQG1lZGlhZHJpdmVyLmNvbXw1Nzc2OTU0fDI4MjkxODI4OQ==>
> .
> NAML
> <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954p5777016.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to