Fwiw, if I had to do it again from scratch, I would not introduce properties for the OSGi bnd instructions again. The main reason is that the maven bundle plugin / bnd tools do make a difference between a property which is not set and a property which is empty. When it's not set, it usually has a good default (for the most used properties). The default values are usually good ones, and it can be very difficult to overcome the fact that the parent plugin defines them as empty.
On the original bnd files / pom problem, I don't really see a major difference. They seem to both have different benefits. Given there's no consensus, I think we should simply revert that change. One thing I don't get is why in the original commit, the bnd instructions in the bnd file are actually different from the ones in the pom. Any explanation ? 2016-02-15 23:36 GMT+01:00 Christian Schneider <ch...@die-schneider.net>: > 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 <l...@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 > > -- > > l...@code-house.org > > Twitter: ldywicki > > Blog: http://dywicki.pl > > Code-House - http://code-house.org > > > > > > > Wiadomość napisana przez Morgan <morgan.haut...@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 > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
