OK, we got a point:
2 PMCs votes -1, 1 PMC asked to revert, 1 PMC said 0, 1 PMC said +1
So we got a consensus: obviously, we have to revert the change and back
on using instructions in pom.xml (and remove bnd files).
I gonna do the change.
Thanks all for this healthy discussion.
Regards
JB
On 02/16/2016 08:46 AM, Guillaume Nodet wrote:
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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
