You are correct.  I think I very much took a view from myself.  I am a user
of karaf but there have been a number of times when I had to troubleshoot
an issue and debug some of the more development code.  I also base my
coding style very much on the open source code written by more experienced
people.  The coding style you choose will likely influence the coding style
of many of the users.  There is a grey line between dev and user when it
comes to OSGI but the people who write the code should be the ones to
choose that style.  Whatever style you choose I am sure everyone will
adjust to well and it is your hard work and knowledge that makes the
project successful.  Not the tools surrounding it.

On Fri, Feb 12, 2016 at 6:53 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi David,
>
> For now, we are talking on the dev side of Karaf: from an user
> perspective, it doesn't change anything (an user doesn't have to know bnd
> to use Karaf).
>
> Anyway, projects using Karaf can still use the configuration they want:
> maven-bundle-plugin without bnd files, bndtools, or whatever.
>
> Regards
> JB
>
>
> On 02/12/2016 12:50 PM, David Daniel wrote:
>
>> I have had the same experience as Milen and Christian but I think I come
>> to
>> a different conclusion.  I originally came to karaf because of the easy
>> entrance into OSGI and we have a Maven build process that I could not move
>> from.  I think many other people come to karaf for those same reasons.
>> Here is a conversation I had the other day where karaf was primarily being
>> used for its build process and its tight integration of maven with
>> features
>>
>> https://groups.google.com/a/saiku.meteorite.bi/forum/#!topic/dev/4uiWj1g2EU0
>> I think even bnd is getting away from having to put things inside of the
>> bnd file and making sure you can configure osgi in other ways (Example
>> would be making classes ending in impl private and using annotations to
>> determine exports and imports through references.  Even those elements you
>> discussed previously such as runtime properties and system packages are
>> more for the bndrun files so that bndtools can package and launch
>> appropriately.  I generally keep them out of the bnd file and let maven
>> handle those elements for my project.  If you want to maintain a bndrun
>> file to test and use with bndtools that is different than requireing a bnd
>> file.  My general feeling is that almost nothing will need to go into the
>> .bnd file soon (See this conversation
>> https://groups.google.com/forum/#!topic/bndtools-users/yV_B5B1cU3k) so
>> karaf should not require users to understand what it is.  I think it will
>> be optional soon enough so it is better not to require it now.  On the
>> other hand if developers like bnd tools then let them include an optional
>> bndrun file that they are responsible for maintaining.  I think with java
>> 9
>> alot of people will come to OSGI for the tooling and it will be important
>> to ease them into the OSGI build process as simply as possible.
>>
>> On Fri, Feb 12, 2016 at 6:28 AM, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>>
>> On 12.02.2016 11:46, Milen Dyankov wrote:
>>>
>>> For the record (in case you find some public evidence of me arguing the
>>>> opposite) some time ago I was totally against using bnd.bnd files. After
>>>> being kind of forced to do it for a while, I realized it doesn't really
>>>> make any difference in the effort that it takes to maintain those and at
>>>> the same time provides clearer separation of concerns. So I changed my
>>>> mind
>>>> :) !
>>>>
>>>> Interestingly I have the same experience. I first hit bnd.bnd files in
>>> some pax projects and thought they were a strange way to configure the
>>> OSGi
>>> setup. So at this time I was also rather against it. The more I worked on
>>> it in pax and also while I did some experiments in bndtools the more I
>>> liked the
>>> style of bnd files. At some point then I migrated the Aries JPA project
>>> to
>>> it and I really like the result.
>>>
>>> Christian
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to