camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <qu...@pronoia-solutions.com>
Subject Re: Usage of Lambdas in our Maven build (jdk8-lambdas branch)
Date Tue, 29 Mar 2016 17:12:50 GMT
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.ibsen@gmail.com> wrote:
> 
> On Tue, Mar 29, 2016 at 4:27 PM, Raul Kripalani <raulk@apache.org <mailto:raulk@apache.org>>
wrote:
>> On Tue, Mar 29, 2016 at 6:21 AM, Claus Ibsen <claus.ibsen@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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message