karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: bnd files in Decanter Project
Date Fri, 12 Feb 2016 12:02:45 GMT
Sorry JB I think you are wrong with this perception. A lot of the dev
decisions do influence users, especially the ones were people build on top.

sent from mobile device
Am 12.02.2016 12:53 nachm. schrieb "Jean-Baptiste Onofré" <jb@nanthrax.net>:

> 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 <
>> chris@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

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