Hi I see this little WARN when its building camel-parent
[INFO] --- maven-bundle-plugin:3.0.1:manifest (bundle-manifest) @ camel-parent --- [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] We should filter out packaging=pom if possible so the bundle plugin do not run on these. On Thu, Mar 31, 2016 at 8:52 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > So far I got > > ftp > mvel > > components to fail in the osgi tests. Have not checked why. > > On Wed, Mar 30, 2016 at 9:24 PM, Raul Kripalani <ra...@apache.org> wrote: >> Changes are pushed now. First commit with lambdas done too ;-) >> >> Gotta keep an eye on Jenkins tonight. >> >> BTW - OSGi Karaf tests were 100% OK. Thanks for the script, Claus. >> >> Cheers, >> >> *Raúl Kripalani* >> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and >> Messaging Engineer >> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >> Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk> >> >> On Wed, Mar 30, 2016 at 7:00 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> >>> On Wed, Mar 30, 2016 at 5:12 PM, Raul Kripalani <r...@evosent.com> wrote: >>> > Yep, today, hopefully. >>> > >>> > Faced a few complications with the Camel Blueprint and Camel Spring >>> > bundles, which were inlining other modules via the bundle plugin. >>> > >>> >>> Yeah there is some ant tasks that copy the source of camel-core-osgi >>> and camel-core-xml AFAIR. >>> There were OSGi problems back then to make those as individual bundles. >>> So having it all in the same bundle made it work. >>> >>> >>> > 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> >>> >> >>> >> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> http://davsclaus.com @davsclaus >>> Camel in Action 2: https://www.manning.com/ibsen2 >>> > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2