Yep, today, hopefully. Faced a few complications with the Camel Blueprint and Camel Spring bundles, which were inlining other modules via the bundle plugin.
Cheers, Raúl. On 30 Mar 2016 16:06, "Quinn Stevenson" <qu...@pronoia-solutions.com> wrote: > 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> > >
