The OSGi Alliance exists because of the companies that step forward to fund it. Then - over and above this financial commitment - those same companies actively put engineering resources into drive OSGi specifications, CT’s & RI’s - many of which are then used by the OSS world including this community.
We do have a program for non-commercial Academic Institutions. But commercial organisations do need to pay their dues. For reference, we are only talking $5K a year for Contributing Associate. Hardly excessive? Best Wishes Richard > On 26 Nov 2015, at 07:03, Jean-Baptiste Onofré <[email protected]> wrote: > > As a company, I know that it's simple. I'm talking with the Talend board, but > unfortunately, I'm not sure that Talend would be interested to participate in > the OSGi Alliance. > > Maybe we can talk together about the "personal participation" related to > OpenSource/Apache projects. > > WDYT ? > > Regards > JB > > On 11/26/2015 07:59 AM, Richard Nicholson wrote: >> Jean-Baptist >> >> Re: Joining the OSGi Alliance is simple. I’d be happy to walk your Talend >> management through the process. >> >> Best Wishes >> >> Richard >> >> >> >>> On 26 Nov 2015, at 06:51, Jean-Baptiste Onofré <[email protected]> wrote: >>> >>> Hi David, >>> >>> We created features instead of using directly OBR as OBR doesn't cover the >>> needs (features contain transitive features, configuration, bundles, etc). >>> Generating a feature from OBR repository will result to incomplete and >>> limited features IMHO. >>> >>> As bndtools is a design/development time, I would prefer that it can >>> generate a complete feature. >>> >>> I agree that a spec enhancement, containing a mix feature (as a generic >>> OSGi feature), subsystem, OSGi Repositories (new name of OBR) can be >>> interesting. >>> As I said in another e-mail, I would be more than happy to participate, but >>> as Apache is not a company and can't pay the OSGi Alliance, it's not easy >>> for us to be part of the OSGi Alliance (other than being employee of a >>> company already member of the OSGi Alliance). >>> >>> Regard >>> JB >>> >>> On 11/26/2015 07:13 AM, David Leangen wrote: >>>> >>>> Hi JB, >>>> >>>> If a plugin is required to create a features set for each development >>>> environment, that would probably create a lot of extra work. >>>> >>>> If instead a features set could be generated from a generic OBR >>>> repository, then the solution would be generalised to any development >>>> environment. Instead of Karaf features being something totally >>>> different, it would instead be layered on top of the OBR spec. I think >>>> adding a “karaf feature” capability to one or more bundles in a >>>> repository not only makes sense, but is exactly the purpose of the whole >>>> capability / requirement principle. >>>> >>>> At least, those are my thoughts… >>>> >>>> Also, when development, I would prefer to simply have one type of >>>> (generic) output, rather than have to specialise my output depending on >>>> the runtime environment. I can imagine a set of annotations that would >>>> make feature creating really simple. >>>> >>>> Maybe this would be a candidate for a spec update, though I am getting >>>> into very unknown territory, as I am by no means an expert in the OSGi >>>> spec. >>>> >>>> >>>> My 2yen. >>>> >>>> Cheers, >>>> =David >>>> >>>> >>>> >>>> On Nov 26, 2015, at 2:34 PM, Jean-Baptiste Onofré <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> Hi David, >>>>> >>>>> It would be great if bndtools is able to "generate" the features. >>>>> >>>>> I know that Christian discussed with bndtools guys about that, and I'm >>>>> also jumping in bndtools to help. >>>>> >>>>> WDYT ? >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On 11/26/2015 01:36 AM, David Leangen wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> If it’s any help, I am also using bndtools in Eclipse/gradle. I am in a >>>>>> greenfield environment, so it is probably easier for me. >>>>>> >>>>>> Thanks to the help of the kind people in this community, I was able to >>>>>> get my release process working. I do this by releasing my bundles from >>>>>> bndtools, then having Karaf pull in the bundles from that repository. I >>>>>> actually like this way of passing the baton, as it nicely decouples my >>>>>> development environment from my deployment environment, using the >>>>>> standard OBR repository as the intermediary. >>>>>> >>>>>> My only remaining challenge is, since Karaf is centred around features, >>>>>> to figure out how to convert my bnd “application” bundle into a feature. >>>>>> This is the bundle that pulls in all the other necessary bundles based >>>>>> on direct and transient requirements. Clearly, the “application” bundle >>>>>> performs the same function as a Karaf feature, so this would be an >>>>>> interesting avenue to explore. >>>>>> >>>>>> If possible this week I will experiment with adding a “Karaf Feature” >>>>>> capability to my application bundle, so that when the repository is >>>>>> installed, any bundle with this capability will be added to a >>>>>> corresponding feature, which would also get installed into the system. >>>>>> If this works as I expect, and if the community is interested, I could >>>>>> try to submit a pull request. >>>>>> >>>>>> Getting back to the title, “Bndtools & Karaf : the right way”, I think >>>>>> that this would be the “right” way to do it. :-) >>>>>> >>>>>> >>>>>> Cheers, >>>>>> =David >>>>>> >>>>>> >>>>>> On Nov 26, 2015, at 4:29 AM, [email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected]> wrote: >>>>>> >>>>>>> Yes agreed, >>>>>>> >>>>>>> I have found that my reasons for leaving the maven-bundle-plugin >>>>>>> were artificial. You do not need a custom package type because you >>>>>>> can map the lifecycle steps yourself. You can still configure it for >>>>>>> a bnd file and even if it imports by default you can manually >>>>>>> configure it to exclude by default and set all your imports. What I >>>>>>> was trying to get across was that there are a lot of great options out >>>>>>> there for how to configure your environment and there is no "the right >>>>>>> way". In my opinion karaf is maven centered where as bnd is centered >>>>>>> on eclipse and its workspaces but they are coming together nicely. It >>>>>>> may take some time to find the tools you like but there are a lot of >>>>>>> really smart people out there that can help you get just the >>>>>>> environment you like. >>>>>>> >>>>>>> >>>>>>> David Daniel >>>>>>> >>>>>>> >>>>>>> On 2015-11-25 14:20, Achim Nierbeck wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> just for the record with the maven-bundle-plugin you can also use the >>>>>>>> bnd file, just configure the pom accordingly. >>>>>>>> regards, Achim >>>>>>>> >>>>>>>> 2015-11-25 16:51 GMT+01:00 <[email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> <mailto:[email protected]>>: >>>>>>>> >>>>>>>> I think different people handle things in different ways. Most >>>>>>>> people who work on karaf seem to use the maven bundle plugin with >>>>>>>> pax-exam for testing. The maven-bundle-plugin uses bnd tools >>>>>>>> underneath and just moves the configuration into your pom file >>>>>>>> instead of .bnd or .bndrun file. What I have been moving to as a >>>>>>>> very beginner in karaf is the bnd-maven-plugin and >>>>>>>> bnd-indexer-plugin. These allow for tighter integration with bnd >>>>>>>> tools but are really alpha in bnd tool 3.1 You have to get the >>>>>>>> builds from bnd tools ci and they don't have support for bnd >>>>>>>> tools running and packaging. I also find myself taking all the >>>>>>>> features that I use from karaf and coping the information in >>>>>>>> there to bnd files so I can run test and package from bnd tools >>>>>>>> which is a lot of duplication of work. Bnd Tools is working on >>>>>>>> adding better maven support but they are really built up around >>>>>>>> eclipse and gradle at this time. I think you will have to find >>>>>>>> what works for you and what features you like. >>>>>>>> >>>>>>>> >>>>>>>> David Daniel >>>>>>>> >>>>>>>> >>>>>>>> On 2015-11-25 09:41, deadbrain wrote: >>>>>>>> >>>>>>>> Hi all Karaf gurus, >>>>>>>> just a little question dealing with BndTools, I am supposed >>>>>>>> to refactor >>>>>>>> an existing Spring DM application into an OSGi + Blueprint >>>>>>>> application >>>>>>>> to be deployed inside ServiceMix (3.4 or 4). As a >>>>>>>> consequence I would >>>>>>>> like to use Bndtools but launching Karaf rather than the >>>>>>>> defaut Gogo >>>>>>>> shell would be more convenient. >>>>>>>> What is the best way to do that ? >>>>>>>> I am supposed to write or reuse an ApplicationFactory ? I >>>>>>>> found a couple >>>>>>>> of implementations in github (ready to use ?) >>>>>>>> Is there any other valuable option? >>>>>>>> >>>>>>>> Kind regards >>>>>>>> Jerome >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Apache Member >>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>>>>> Committer & Project Lead >>>>>>>> blog <http://notizblog.nierbeck.de/> >>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>>>>> Software Architect / Project Manager / Scrum Master >>>>>> >>>>> >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> [email protected] <mailto:[email protected]> >>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/> >>>>> Talend -http://www.talend.com <http://www.talend.com/> >>>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
