karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: bnd files in Decanter Project
Date Mon, 15 Feb 2016 20:40:42 GMT
I would like to give my -1 for usage of bnd files for now.

I would like to stay consistent between karaf and it’s children and it’s not yet time
for bndtools. Even if it’s looks nice we don’t jump into it for the same reason we do
not jump into tycho which offers manifest first approach. It’s not because its better or
worse, it’s because we do things in our way. Our primary build tool is maven and always
have been. The way we have built Karaf was example for many people to build their own applications
thus without futher discussion and notification to user/developers providing deeper information
about migration we can’t do that. I see discussion happening partialy here so my arguments
to stay-as-is:

- Argument about smaller number of code can be easily overthrown by usage of inheriting plugin
setup (see https://github.com/FasterXML/oss-parent/commit/5f228dbcdf1f6c6cb0c5067385cd4e7432cbda1b
where I prepared configuration for jackson and it’s submodules) maven will be then just
+2 LOC for <properties> tags compared to bnd file.
- Declaration of imports in parent module supported by bnd is bad practice just as declaring
maven dependencies in parents.
- Usage of properties for import/exports is way to go since it’s verified by maven-bundle-plugin,
this is variable part of maven build and I don’t think throwing it out to *.bnd file is
necessary. Also with proper setup we can use bundle namespaces such bundle.namespace=${project.groupId}.${project.artifactId}
to automaticaly export contents and limit visibility (export: !${bundle.namespace}.internal)
so only one thing needed will be bundle packaging. If bnd file is just property file then
we don’t need it. If it does something more than being property file - we don’t want that
- Possibility to do more things in bnd file may just complicate things more than they should
be (more magic means harder maintanance), especially for people who are trying to understand
what is happening with build. Bnd definitely doesn’t have nicest code so the less complicated
our usage is the better it is for all of us. Here I just prefer to be more explicit than implicit.
I am aware maven bundle plugin just covers bnd but we used it for years and it did great job
so far. I am aware that bnd offers plugins but we don’t want to use them since we stick
with maven which offers the same functionality and we should not split that into multiple

I appreciate your work and constant improvement you are making for community, however we can
satisfy your need to reduce code without any bigger changes in the way we configure projects.
If entire discussion is about justification for "just" new file - we can easily live without
it. If it’s about introducing another tool into build chain - we don’t need it and it
should be discussed in separate thread, but most likely most of arguments at this stage will
be repeated.

Kind regards,
Łukasz Dywicki
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org

> Wiadomość napisana przez Morgan <morgan.hautman@gmail.com> w dniu 13 lut 2016,
o godz. 11:22:
> Hi,
> After discussing with Christian I would like to revert my -1 to a +1.
> Christian gave me some interesting arguments so I'm not against it anymore.
> Regards;
> Morgan
> On 2016-02-11 11:05, Morgan Hautman wrote:
>> Hi,
>> I'm also giving my -1, as I see no added value on this.
>> Regards,
>> Morgan
>> On 02/11/2016 09:55 AM, Achim Nierbeck wrote:
>>> Hi,
>>> the other day I added another module to the decanter project (cassandra
>>> appender).
>>> And I've got to say I was quite astonished to see all those bnd files in
>>> there, but what
>>> really got me stirred. It is mandatory to have those now.
>>> I can't remember seeing a vote for such a change in development!
>>> So here is my
>>> -1
>>> on this not communicated and breaking functionality change that sneaked in
>>> there.
>>> So whoever changed that needs to revoke this, NOW.
>>> It hasn't been discussed up-front and actually I just can't stand such
>>> sneaky moves.
>>> regards, Achim

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