Any updates on when this will be merged? I have a couple of PRs I’m working on that this effects.
> On Mar 29, 2016, at 11:12 AM, Quinn Stevenson <qu...@pronoia-solutions.com> > wrote: > > For the JARs that will not be bundles - what do we want in the MANIFEST.MF? > > >> On Mar 29, 2016, at 9:59 AM, Claus Ibsen <claus.ib...@gmail.com >> <mailto:claus.ib...@gmail.com>> wrote: >> >> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <ra...@apache.org >> <mailto:ra...@apache.org>> wrote: >>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ib...@gmail.com >>> <mailto:claus.ib...@gmail.com>> wrote: >>> >>>> Can we flip the switch so you have to enable it on the maven modules >>>> that you want to be an osgi bundle. I am asking because people who are >>>> not using OSGi should really not see camel.osgi.skip=true in the >>>> examples / camel-spring-boot-starter etc. >>>> >>>> They should be clean and without any osgi stuff. >>>> >>>> Also I would rather make it explicit that this maven module is built >>>> as an osgi bundle if it has camel.osgi=true. >>>> >>> >>> I see your point. What I'll do is make the activation rely on property >>> value comparison rather than property presence, e.g. camel.osgi=true/false. >>> That way, we can set camel.osgi=true on components/pom.xml, and exclude >>> only the few components that are not OSGi by setting camel.osgi=false on >>> their POMs. >>> For the examples, we can set camel.osgi=false on examples/pom.xml, and only >>> set the property to true on those examples that are meant to be bundles. >>> Let's play with value rather than presence/absence, because once you set a >>> property up the chain in the Maven reactor, I don't think you can unset it >>> (or can you?). >>> >>> Although... Approaching it from a different angle, it may be worth to >>> explicitly define the build plugins in each example POM. Thus we can >>> attempt to make the example "self-contained". >>> >> >> Yeah would love to make the examples self container without a parent. >> And then they should import the Camel BOM instead (aka camel parent). >> >> Then end users can just copy those and adjust them as needed. >> >> Not sure if we have tried this in the past and had trouble with the >> release build? >> And there is 50+ examples so a fair bit of work to migrate. But we >> have a big community so people can help with this. >> >> >>> That would take more work, so I won't do it now, but just wanted to hear >>> your thoughts. >>> >> >> Yeah sounds good. >> >>> Cheers, >>> >>> *Raúl Kripalani* >>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and >>> Messaging Engineer >>> http://about.me/raulkripalani <http://about.me/raulkripalani> | >>> http://www.linkedin.com/in/raulkripalani >>> <http://www.linkedin.com/in/raulkripalani> >>> Blog: raul.io <http://raul.io/> | twitter: @raulvk >>> <https://twitter.com/raulvk <https://twitter.com/raulvk>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com <http://davsclaus.com/> @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >> <https://www.manning.com/ibsen2>
