karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: bnd files in Decanter Project
Date Mon, 15 Feb 2016 22:36:26 GMT
Hi Lukasz,

thanks for weighing in here. I almost thought there would be no more
feedback from other pmc members than Achim and JB.

Coming to the factual arguments I do not get how these ugly constructs of
maven bundle plugin parent setup + properties is better in any way then a
small bnd file. The big problem with the properties is that basically
everyone can and will name them differently. So if you look at two projects
constructed in such a way the OSGi setup will look very different. At least
what I really like in your example compared to the aries one is that you do
not impose certain rules on the developer. In aries it was really bad that
for example a standard export would be named like the groupid ( I think).
So it really caused big issues if your package name was not like the group
id as you could not override it.

I think bnd files make projects easier to understand and they are a lot
smaller regarding the code.
In your example where you need two lines of properties to define the module
it would also be two lines in a bnd file but the parent would be a lot
smaller and simpler.

You are right that declaring imports in the parent is a bad practice be it
the properties based aproach or the bnd based approach.

Why do you say the properties are THE way to go (or did you mean a way to
go) then I agree? Yes they are validated by the maven-bundle-plugin but the
definitions in the bnd file are validated by the maven bundle plugin in the
same way. So both are a safe way to define OSGi settings.

The bnd files allow to do exactly the same things as the maven bundle
plugin configuration. Please do not confuse the bnd files that bndtools
uses with the one of the maven bundle plugin.

Also please be  assured that I do not intend to introduce bndtools. My
intent it to stay with the maven bundle plugin and just use bnd files as a
shorter way to define the maven bundle plugin configuration. I am only
looking into bndtools in private. It will be quite a way till bndtools will
fully support our maven builds. If at some point I would propose bndtools
then it would be in a way that keeps our maven builds in place.

Having said all this I only have a slight preference of the bnd file style
compared to the style you suggested. I think the style you proposed is a
valid alternative. I prefer the bnd style but if the majority is for your
style I am also fine with it.

Christian


2016-02-15 21:40 GMT+01:00 Łukasz Dywicki <luke@code-house.org>:

> 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
> <
> 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 too.
> - 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 places.
>
> 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
> --
> luke@code-house.org
> 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
> >>>
> >>
> >
>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>

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