bnd files in Decanter Project

[Achim Nierbeck <bc...@googlemail.com>]

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

-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Maybe yes. Not sure. It's not obvious to me that using bnd files has an 
impact on end users.

For instance, for Decanter, users just do feature:install, however the 
bundles have been created.

Maybe I'm wrong.

Regards
JB

On 02/12/2016 01:02 PM, Achim Nierbeck wrote:
> 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
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: bnd files in Decanter Project

[Achim Nierbeck <bc...@googlemail.com>]

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
>

Re: bnd files in Decanter Project

[David Daniel <da...@gmail.com>]

You are correct.  I think I very much took a view from myself.  I am a user
of karaf but there have been a number of times when I had to troubleshoot
an issue and debug some of the more development code.  I also base my
coding style very much on the open source code written by more experienced
people.  The coding style you choose will likely influence the coding style
of many of the users.  There is a grey line between dev and user when it
comes to OSGI but the people who write the code should be the ones to
choose that style.  Whatever style you choose I am sure everyone will
adjust to well and it is your hard work and knowledge that makes the
project successful.  Not the tools surrounding it.

On Fri, Feb 12, 2016 at 6:53 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> 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
>

Re: bnd files in Decanter Project

[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

Re: bnd files in Decanter Project

[David Daniel <da...@gmail.com>]

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
>
>

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

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

Re: bnd files in Decanter Project

[Milen Dyankov <mi...@gmail.com>]

For me personally IDE support is irrelevant. BND is a command like tool and
while support for it in IDEs is different at the end of the day all you
need is a properties file editor. You don't get code competition for POMs
neither so there is absolutely no difference (in terms of amount of work
needed) where you put your instructions. But on the Pro side I would put

 - standard: bnd.bnd is the standard way to configure BND. I just like to
use the right tool for the job. For example, consider if you were using
some "next generation" build tool that runs Maven under the hood, would you
like to have maven configuration in that other fancy tool's config files or
rather stick with maven poms?
 - learning curve: The BND docs have examples how to configure things in
bnd.bnd file and it's not always immediately obvious how to transfer those
to maven plugin configuration.
 - plugin independent configuration - obviously bnd-maven-plugin comes to
mind first but in general if someone comes with better (in whatever sense)
plugin in the future the configuration does not need to change

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
:) !

Best,
Milen


On Fri, Feb 12, 2016 at 11:05 AM, Christian Schneider <
chris@die-schneider.net> wrote:

> From my point of view the arguments for and against the bnd file
> extraction.
>
> Pro:
> - You typically do not need a plugin definition at all in each module pom.
> So the definition just in the bnd file is much more concise.
> - If you use bndtools you get a nice view and editor for the bnd file.
> This is not so important for me though.
>
> Con:
> - If you use intellij then most probably you will have some completion
> support for the configurations in the pom but not for the bnd.bnd file
>
> So I think the extraction is best for users of eclipse and bndtools and
> less valuable for other IDEs. To be honest though editing the bnd files is
> not really a big deal.
> I typically only use Import-Package, Export-Package, Private-Package and
> Bundle-Activator and these four I can type without completion. The maven
> bundle plugin also nicely
> complains if you have any errors in the file. So I think editing with a
> simple text editor is no big deal.
>
> Christan
>
>
> On 12.02.2016 10:54, Markus Rathgeb wrote:
>
>> Hi Christian,
>> thank you for your answer.
>>
>> I want to state, that there are no feelings from my side what is better.
>> I want to collect the technical details for further decisions on the
>> projects I maintain.
>>
>> So, let's assume I do not use the configuration in a parent project
>> (just add maven-bundle-plugin to the used plugins and set
>> extensions=true) and also not use properties, the bnd.bnd file will
>> result in less lines in the pom if I want to change the default
>> configuration of the plugin.
>>
>> Are there other pros?
>>
>> Best regards,
>> Markus
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
http://about.me/milen

Re: bnd files in Decanter Project

[Markus Rathgeb <ma...@gmail.com>]

Hi,

> - You typically do not need a plugin definition at all in each module pom.
> So the definition just in the bnd file is much more concise.

I set the plugin with "<_dsannotations>*</_dsannotations>" and set
extensions in the parent POM and so no child pom that is using the
defaults does need to contain the maven-bundle-plugin section at all.

> So I think the extraction is best for users of eclipse and bndtools and less
> valuable for other IDEs. To be honest though editing the bnd files is not
> really a big deal.

> I typically only use Import-Package, Export-Package, Private-Package and
> Bundle-Activator and these four I can type without completion.

Thank you again for your explanations.

I (!) see no real pro and no real cons.
So IMHO it is just a personal decision if someone want to use bnd.bnd
files or not and perhaps the IDE that is used to configure stuff and
work with.

Best regards,
Markus

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

 From my point of view the arguments for and against the bnd file 
extraction.

Pro:
- You typically do not need a plugin definition at all in each module 
pom. So the definition just in the bnd file is much more concise.
- If you use bndtools you get a nice view and editor for the bnd file. 
This is not so important for me though.

Con:
- If you use intellij then most probably you will have some completion 
support for the configurations in the pom but not for the bnd.bnd file

So I think the extraction is best for users of eclipse and bndtools and 
less valuable for other IDEs. To be honest though editing the bnd files 
is not really a big deal.
I typically only use Import-Package, Export-Package, Private-Package and 
Bundle-Activator and these four I can type without completion. The maven 
bundle plugin also nicely
complains if you have any errors in the file. So I think editing with a 
simple text editor is no big deal.

Christan

On 12.02.2016 10:54, Markus Rathgeb wrote:
> Hi Christian,
> thank you for your answer.
>
> I want to state, that there are no feelings from my side what is better.
> I want to collect the technical details for further decisions on the
> projects I maintain.
>
> So, let's assume I do not use the configuration in a parent project
> (just add maven-bundle-plugin to the used plugins and set
> extensions=true) and also not use properties, the bnd.bnd file will
> result in less lines in the pom if I want to change the default
> configuration of the plugin.
>
> Are there other pros?
>
> Best regards,
> Markus


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Markus Rathgeb <ma...@gmail.com>]

Hi Christian,
thank you for your answer.

I want to state, that there are no feelings from my side what is better.
I want to collect the technical details for further decisions on the
projects I maintain.

So, let's assume I do not use the configuration in a parent project
(just add maven-bundle-plugin to the used plugins and set
extensions=true) and also not use properties, the bnd.bnd file will
result in less lines in the pom if I want to change the default
configuration of the plugin.

Are there other pros?

Best regards,
Markus

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

Hi Markus,

we had this configuration (and in most modules still have it) in Aries.
The big problem is that if you setup for example an Import-Package in
the parent pom then you can not change it back to the default in a 
submodule.
This caused a lot of problems in Aries. If you look into the links below 
you see how verbose the setup is and how easy it is to configure it wrong.

I also do not like the approach of using properties for OSGi configs as 
they are just arbitrary strings. So it is really easy to mess up.
I think the maven-bundle-plugin uses pretty good defaults so the default 
config is a good start and tweaking the config per module as necessary
produces good results.

I have also looked a bit into the bnd-maven-plugin. I generally like the 
approach of being less invasive regarding the build. I have not used it 
in a bigger project though.


For reference this is the setup in Aries:
Properties
https://github.com/apache/aries/blob/trunk/parent/pom.xml#L184-L213
Baselining
https://github.com/apache/aries/blob/trunk/parent/pom.xml#L393-L410
Maven bundle plugin
https://github.com/apache/aries/blob/trunk/parent/pom.xml#L529-L557
One of the modules
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/pom.xml#L48-L91


To compare. This is the setup of the jpa subproject.
Maven bundle plugin and baselining
https://github.com/apache/aries/blob/trunk/parent/pom.xml#L185-L213
One of the modules
https://github.com/apache/aries/blob/trunk/jpa/jpa-container/osgi.bnd

If you compare the two approaches you see how much simpler the setup 
with no big defaults and an extracted bnd file is in the jpa sub 
project. A small part of the simplicity comes from the bnd file 
extraction but the much bigger part comes from simply leaving the defaults.

Christian


On 12.02.2016 09:26, Markus Rathgeb wrote:
> Hello,
>
> some related questions:
>
> You are talking about the bnd-maven-plugin (e.g. Neil Bartlett). I
> recently read this pages:
> * https://github.com/bndtools/bnd/issues/629
> * https://github.com/bndtools/bndtools/wiki/Maven-Integration-Requirements
> So, I would assume I should not move my projects to use that plugin.
> Correct?
>
> Could we collect pro and cons of he bnd.bnd files at some place?
> The only pro I have read is loosing some lines.
> This could also be done using a pre-configured maven-bundle-plugin in
> the parent POM and using properties to change that stuff (see e.g.
> https://github.com/ops4j/org.ops4j.pax.tipi/blob/master/tipi-master/pom.xml).
> Or I am wrong?
>
> Best regards,
> Markus


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Markus Rathgeb <ma...@gmail.com>]

Hello,

some related questions:

You are talking about the bnd-maven-plugin (e.g. Neil Bartlett). I
recently read this pages:
* https://github.com/bndtools/bnd/issues/629
* https://github.com/bndtools/bndtools/wiki/Maven-Integration-Requirements
So, I would assume I should not move my projects to use that plugin.
Correct?

Could we collect pro and cons of he bnd.bnd files at some place?
The only pro I have read is loosing some lines.
This could also be done using a pre-configured maven-bundle-plugin in
the parent POM and using properties to change that stuff (see e.g.
https://github.com/ops4j/org.ops4j.pax.tipi/blob/master/tipi-master/pom.xml).
Or I am wrong?

Best regards,
Markus

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

I'm looking forward the beers ;)

Enjoy your week end mate

Regards
JB

On 02/12/2016 08:38 AM, Achim Nierbeck wrote:
> Of course I accept those apologies.
> I'm sorry for being harsh, I had my reason and people longer to the project
> will know why I blew the top (kragen geplatzt in German).
>
> Next time we'll meet I'll pay the both of them a beer.
>
> Regards, Achim
>
> sent from mobile device
> Am 12.02.2016 6:39 vorm. schrieb "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
>
>> Hi guys,
>>
>> let me defuse the bomb ;)
>>
>> 1. Christian and I were sorry about our leak of communication. I'm as
>> faulty as Christian, as he discussed about the change with me, I agreed,
>> but I should have reminder to start a discussion on the mailing list. So
>> another time, I'm sorry about that, and really apologize.
>> 2. Now, Christian sent factual arguments about the change. Some can
>> disagree, providing arguments, it's the way to do it.
>>
>> However, guys, I know that I already pissed you bunch of time with that,
>> but let me do it again:
>> - we are a team, an open source project is not an individual effort. So,
>> we have to act as a team. Be always open minded, eager to discuss in a fair
>> way.
>> - on the mailing list, please, keep a relax, cool (and maybe fun ;)) tone.
>> We have different culture and background, and some words may sound
>> different. Propose, never impose. Educate, never be harsh. Discuss, never
>> order. Don't think you are better than other or the best, we are all noob
>> and all proposal can make sense. Accept the mistake, because you will do a
>> mistake one day ;)
>>
>> I'm probably "old school minded", or it's maybe my rugby player way of
>> thinking, but, relax, take a beer with the pal, and thinks will improve.
>>
>> We do a great job in Karaf: it's not because we are the best, it's just
>> because we do the job all together, always with the users, and listening
>> proposal and arguments.
>>
>> A smart and wise guy (especially developer) is able to change his mind
>> bunch of time ;)
>>
>> So guys, relax, and keep moving forward !
>>
>> Regards
>> JB
>>
>> On 02/11/2016 08:19 PM, Christian Schneider wrote:
>>
>>> Hi Achim,
>>>
>>> thanks for your detailed description. I can assure you that I do not
>>> follow any evil plot like you seem to think. I will for sure not use
>>> gradle any time soon. I am quite happy with maven and am just trying to
>>> make our project better and the code more efficient. I also was not
>>> really sneaky by creating an issue up front and describing what I want
>>> to do. I just did not to also spawn a discussion on the list to make
>>> this more obvious. Please be assured that the only reason for this was
>>> my inherent impatience and good faith that JB would not have supported
>>> my change if he thought it would be a bad thing for the karaf community.
>>> So I was not really aware of doing something wrong at this time.
>>>
>>> Please also take into account that your build problem only happened on a
>>> new module you wanted to add and could be fixed by just adding the empty
>>> bnd.bnd file. So I think a -1 while possible was not really necessary. I
>>> think the better option would have been to bring the issue on the list
>>> and try to reach a consensus. I think in my whole apache history I never
>>> did a -1 on a commit.
>>>
>>> Do you insist on me taking back the commit now or would it be ok to
>>> first try to reach a consensus or if not possible do a vote? I will
>>> happily undo my commit if the outcome is to not do the change. On the
>>> other hand if we agree to do the change it would save me to shuffle the
>>> code back and  forth.
>>>
>>> If you insist on this I will undo the changes now. It is probably not
>>> possible to just undo the commit as there are quite a few commits in
>>> between. So it will be quite some manual work for me.
>>> I also hope that if you insist on me taking back the change now you are
>>> ok if I only undo the bnd file part of the commit and leave other
>>> changes like moving some common deps into the parent in place.
>>>
>>> Christian
>>>
>>>
>>> On 11.02.2016 17:06, Achim Nierbeck wrote:
>>>
>>>> Hi there,
>>>>
>>>> I'll stick to my
>>>>
>>>> -1
>>>>
>>>> Now the reasons for this:
>>>>
>>>> Even though the opposite has been proclaimed on the list, it did break
>>>> the
>>>> build for me. As without a bnd file the project isn't building
>>>> successfully, even though the information needed has been provided by the
>>>> pom.
>>>>
>>>> Second the usage of an extra bnd file is error prone, and I don't care
>>>> about removed lines of code, this is just not a justification.
>>>> Another thing why I opposed to extra bnd files. Only on Eclipse when
>>>> using
>>>> the bnd-tools project you have an extra editor available to use it. And
>>>> this only works for people using both, eclipse and the bnd-tools. All
>>>> others using a different tool chain are losing the benefit to see
>>>> everthing
>>>> in one go.
>>>> So basically people using IntelliJ or Netbeans (both tools to be know to
>>>> work far better with maven, then eclipse) are out of this. And I rather
>>>> don't rely on a proprietary tooling for this.
>>>>
>>>> So what's next after this? Just sneak the bnd-tools plugins into this
>>>> project for "supposedly" better support with eclipse and bnd-tools?
>>>> I don't think so. Our basis is still Maven and not Gradle, and this is
>>>> because we have a big user-base that feels very comfortable with it.
>>>> Using the declarations in the pom has been working nicely and if nothing
>>>> needs to be done one just needs to add those 4 lines for the usage of the
>>>> maven-bundle-plugin. No extra file needed, everything is in one place and
>>>> is in line with all other Karaf projects.
>>>> Actually this is one of the reasons I removed those bnd files from the
>>>> pax-web project long time ago, because all those project related
>>>> information are in one place now, instead of scattered around the
>>>> project.
>>>>
>>>> Third, and this does outweigh everything else. Christian tried to provide
>>>> evidence with this move and now argues this way everything is better for
>>>> us.
>>>> At this point I can't accept this. I don't think this is the way our
>>>> community works and surely this isn't the way we work together on our
>>>> sources. At least
>>>> this has been my understanding of a successful project.
>>>> If I'm wrong on this and everybody can do as he likes, I guess I need
>>>> think
>>>> about the consequences.
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>>
>>>>
>>>> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>>
>>>> I see valid arguments here, and I keep my +1.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>>>>>
>>>>> I also did a jira issue that explains the change.
>>>>>> https://issues.apache.org/jira/browse/KARAF-4300
>>>>>>
>>>>>> To show the advantage let me compare one of the old configs to the new
>>>>>> one:
>>>>>> http://apaste.info/gC5
>>>>>>
>>>>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
>>>>>> file.
>>>>>> The syntax is basically the same
>>>>>> as in xml just without the brackets. The big advantage is that we can
>>>>>> leave out the boilerplate xml that maven
>>>>>> needs to redefine a plugin.
>>>>>>
>>>>>> So I think the change to bnd files makes a lot of sense. I also did
>>>>>> this
>>>>>> change in Aries a long time ago.
>>>>>> Btw. I also added API baselining in this change which helps us when do
>>>>>> changes on the API.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> On 11.02.2016 14:21, Christian Schneider wrote:
>>>>>>
>>>>>> As further reference. This is the commit where I did the change:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As you can see I added 108 lines and removed 753.
>>>>>>>
>>>>>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>>>>>> think this is a strong indicator that it is a good idea to do so. Of
>>>>>>> course it might cause problems that I overlooked.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>>>>>
>>>>>>> Hi Achim,
>>>>>>>>
>>>>>>>> it is difficult to predict what changes warrant a discussion. I agree
>>>>>>>> with you that I should have discussed this on the list. I talked to
>>>>>>>> JB and he was positive so I did not expect any problems. Apparently I
>>>>>>>> was wrong :-(
>>>>>>>>
>>>>>>>> The usage of bnd files for configuration of the imports and exports
>>>>>>>> is a very concise replacement for the same configs in xml.
>>>>>>>>
>>>>>>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>>>>>>> pom of each module. So basically you replace about 10-15 lines of xml
>>>>>>>> with 0-5 lines in the bnd file.
>>>>>>>>
>>>>>>>> This does not break any functionality for users. For developers it
>>>>>>>> just requires to put an empty bnd.bnd file into each module if it
>>>>>>>> does not need special configs. Unfortunately it is not possible to
>>>>>>>> define that it uses a bnd file if it is there  and is also happy if
>>>>>>>> no such file is there. I plan to suggest this to the felix project as
>>>>>>>> it would make this even easier to use.
>>>>>>>>
>>>>>>>> In what way do you see this as a breaking change? I made sure that
>>>>>>>> all code still works and that all tests still pass. I also did manual
>>>>>>>> tests of all the modules.
>>>>>>>>
>>>>>>>> So the only thing you need to do for a new module is to add this
>>>>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>>>>>> bnd file to configure your OSGi configs you can use the xml like
>>>>>>>> before.
>>>>>>>>
>>>>>>>> So apart from my bad communication where I fully agree with you.. do
>>>>>>>> you really  think this warrants a -1?
>>>>>>>> Do you have any technical concerns?
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>>>>>> <ma...@googlemail.com>>:
>>>>>>>>
>>>>>>>>       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
>>>>>>>>
>>>>>>>>       --
>>>>>>>>
>>>>>>>>       Apache Member
>>>>>>>>       Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>       OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>       Committer &
>>>>>>>>       Project Lead
>>>>>>>>       blog <http://notizblog.nierbeck.de/>
>>>>>>>>       Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>>
>>>>>>>>       Software Architect / Project Manager / Scrum Master
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: bnd files in Decanter Project

[Morgan Hautman <mo...@gmail.com>]

If there is an open seat and not having a football match I'm in also!

Regards,
Morgan
On Feb 12, 2016 09:28, "Jean-Baptiste Onofré" <jb...@nanthrax.net> wrote:

> I would love to join too !
>
> Regards
> JB
>
> On 02/12/2016 09:21 AM, Christian Schneider wrote:
>
>> Hi Achim,
>>
>> I am glad to resolve this. The second round of beers is on me. I would
>> like to work on building some more trust.
>> How about doing a coding session together on a weekend. I think there is
>> nothing better than working together while having
>> a good time to gain some mutual trust. Perhaps some of the other local
>> karaf enthusiast (like maybebuggy aka Sascha) are willing to join. I can
>> organize the event.
>>
>> Christian
>>
>>
>> On 12.02.2016 08:38, Achim Nierbeck wrote:
>>
>>> Of course I accept those apologies.
>>> I'm sorry for being harsh, I had my reason and people longer to the
>>> project
>>> will know why I blew the top (kragen geplatzt in German).
>>>
>>> Next time we'll meet I'll pay the both of them a beer.
>>>
>>> Regards, Achim
>>>
>>> sent from mobile device
>>> Am 12.02.2016 6:39 vorm. schrieb "Jean-Baptiste Onofré"
>>> <jb...@nanthrax.net>:
>>>
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

I would love to join too !

Regards
JB

On 02/12/2016 09:21 AM, Christian Schneider wrote:
> Hi Achim,
>
> I am glad to resolve this. The second round of beers is on me. I would
> like to work on building some more trust.
> How about doing a coding session together on a weekend. I think there is
> nothing better than working together while having
> a good time to gain some mutual trust. Perhaps some of the other local
> karaf enthusiast (like maybebuggy aka Sascha) are willing to join. I can
> organize the event.
>
> Christian
>
>
> On 12.02.2016 08:38, Achim Nierbeck wrote:
>> Of course I accept those apologies.
>> I'm sorry for being harsh, I had my reason and people longer to the
>> project
>> will know why I blew the top (kragen geplatzt in German).
>>
>> Next time we'll meet I'll pay the both of them a beer.
>>
>> Regards, Achim
>>
>> sent from mobile device
>> Am 12.02.2016 6:39 vorm. schrieb "Jean-Baptiste Onofré"
>> <jb...@nanthrax.net>:
>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

Hi Achim,

I am glad to resolve this. The second round of beers is on me. I would 
like to work on building some more trust.
How about doing a coding session together on a weekend. I think there is 
nothing better than working together while having
a good time to gain some mutual trust. Perhaps some of the other local 
karaf enthusiast (like maybebuggy aka Sascha) are willing to join. I can 
organize the event.

Christian


On 12.02.2016 08:38, Achim Nierbeck wrote:
> Of course I accept those apologies.
> I'm sorry for being harsh, I had my reason and people longer to the project
> will know why I blew the top (kragen geplatzt in German).
>
> Next time we'll meet I'll pay the both of them a beer.
>
> Regards, Achim
>
> sent from mobile device
> Am 12.02.2016 6:39 vorm. schrieb "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
>
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Achim Nierbeck <bc...@googlemail.com>]

Of course I accept those apologies.
I'm sorry for being harsh, I had my reason and people longer to the project
will know why I blew the top (kragen geplatzt in German).

Next time we'll meet I'll pay the both of them a beer.

Regards, Achim

sent from mobile device
Am 12.02.2016 6:39 vorm. schrieb "Jean-Baptiste Onofré" <jb...@nanthrax.net>:

> Hi guys,
>
> let me defuse the bomb ;)
>
> 1. Christian and I were sorry about our leak of communication. I'm as
> faulty as Christian, as he discussed about the change with me, I agreed,
> but I should have reminder to start a discussion on the mailing list. So
> another time, I'm sorry about that, and really apologize.
> 2. Now, Christian sent factual arguments about the change. Some can
> disagree, providing arguments, it's the way to do it.
>
> However, guys, I know that I already pissed you bunch of time with that,
> but let me do it again:
> - we are a team, an open source project is not an individual effort. So,
> we have to act as a team. Be always open minded, eager to discuss in a fair
> way.
> - on the mailing list, please, keep a relax, cool (and maybe fun ;)) tone.
> We have different culture and background, and some words may sound
> different. Propose, never impose. Educate, never be harsh. Discuss, never
> order. Don't think you are better than other or the best, we are all noob
> and all proposal can make sense. Accept the mistake, because you will do a
> mistake one day ;)
>
> I'm probably "old school minded", or it's maybe my rugby player way of
> thinking, but, relax, take a beer with the pal, and thinks will improve.
>
> We do a great job in Karaf: it's not because we are the best, it's just
> because we do the job all together, always with the users, and listening
> proposal and arguments.
>
> A smart and wise guy (especially developer) is able to change his mind
> bunch of time ;)
>
> So guys, relax, and keep moving forward !
>
> Regards
> JB
>
> On 02/11/2016 08:19 PM, Christian Schneider wrote:
>
>> Hi Achim,
>>
>> thanks for your detailed description. I can assure you that I do not
>> follow any evil plot like you seem to think. I will for sure not use
>> gradle any time soon. I am quite happy with maven and am just trying to
>> make our project better and the code more efficient. I also was not
>> really sneaky by creating an issue up front and describing what I want
>> to do. I just did not to also spawn a discussion on the list to make
>> this more obvious. Please be assured that the only reason for this was
>> my inherent impatience and good faith that JB would not have supported
>> my change if he thought it would be a bad thing for the karaf community.
>> So I was not really aware of doing something wrong at this time.
>>
>> Please also take into account that your build problem only happened on a
>> new module you wanted to add and could be fixed by just adding the empty
>> bnd.bnd file. So I think a -1 while possible was not really necessary. I
>> think the better option would have been to bring the issue on the list
>> and try to reach a consensus. I think in my whole apache history I never
>> did a -1 on a commit.
>>
>> Do you insist on me taking back the commit now or would it be ok to
>> first try to reach a consensus or if not possible do a vote? I will
>> happily undo my commit if the outcome is to not do the change. On the
>> other hand if we agree to do the change it would save me to shuffle the
>> code back and  forth.
>>
>> If you insist on this I will undo the changes now. It is probably not
>> possible to just undo the commit as there are quite a few commits in
>> between. So it will be quite some manual work for me.
>> I also hope that if you insist on me taking back the change now you are
>> ok if I only undo the bnd file part of the commit and leave other
>> changes like moving some common deps into the parent in place.
>>
>> Christian
>>
>>
>> On 11.02.2016 17:06, Achim Nierbeck wrote:
>>
>>> Hi there,
>>>
>>> I'll stick to my
>>>
>>> -1
>>>
>>> Now the reasons for this:
>>>
>>> Even though the opposite has been proclaimed on the list, it did break
>>> the
>>> build for me. As without a bnd file the project isn't building
>>> successfully, even though the information needed has been provided by the
>>> pom.
>>>
>>> Second the usage of an extra bnd file is error prone, and I don't care
>>> about removed lines of code, this is just not a justification.
>>> Another thing why I opposed to extra bnd files. Only on Eclipse when
>>> using
>>> the bnd-tools project you have an extra editor available to use it. And
>>> this only works for people using both, eclipse and the bnd-tools. All
>>> others using a different tool chain are losing the benefit to see
>>> everthing
>>> in one go.
>>> So basically people using IntelliJ or Netbeans (both tools to be know to
>>> work far better with maven, then eclipse) are out of this. And I rather
>>> don't rely on a proprietary tooling for this.
>>>
>>> So what's next after this? Just sneak the bnd-tools plugins into this
>>> project for "supposedly" better support with eclipse and bnd-tools?
>>> I don't think so. Our basis is still Maven and not Gradle, and this is
>>> because we have a big user-base that feels very comfortable with it.
>>> Using the declarations in the pom has been working nicely and if nothing
>>> needs to be done one just needs to add those 4 lines for the usage of the
>>> maven-bundle-plugin. No extra file needed, everything is in one place and
>>> is in line with all other Karaf projects.
>>> Actually this is one of the reasons I removed those bnd files from the
>>> pax-web project long time ago, because all those project related
>>> information are in one place now, instead of scattered around the
>>> project.
>>>
>>> Third, and this does outweigh everything else. Christian tried to provide
>>> evidence with this move and now argues this way everything is better for
>>> us.
>>> At this point I can't accept this. I don't think this is the way our
>>> community works and surely this isn't the way we work together on our
>>> sources. At least
>>> this has been my understanding of a successful project.
>>> If I'm wrong on this and everybody can do as he likes, I guess I need
>>> think
>>> about the consequences.
>>>
>>> regards, Achim
>>>
>>>
>>>
>>>
>>> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>
>>> I see valid arguments here, and I keep my +1.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>>>>
>>>> I also did a jira issue that explains the change.
>>>>> https://issues.apache.org/jira/browse/KARAF-4300
>>>>>
>>>>> To show the advantage let me compare one of the old configs to the new
>>>>> one:
>>>>> http://apaste.info/gC5
>>>>>
>>>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
>>>>> file.
>>>>> The syntax is basically the same
>>>>> as in xml just without the brackets. The big advantage is that we can
>>>>> leave out the boilerplate xml that maven
>>>>> needs to redefine a plugin.
>>>>>
>>>>> So I think the change to bnd files makes a lot of sense. I also did
>>>>> this
>>>>> change in Aries a long time ago.
>>>>> Btw. I also added API baselining in this change which helps us when do
>>>>> changes on the API.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On 11.02.2016 14:21, Christian Schneider wrote:
>>>>>
>>>>> As further reference. This is the commit where I did the change:
>>>>>>
>>>>>>
>>>>>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>>>>
>>>>>>
>>>>>>
>>>>>> As you can see I added 108 lines and removed 753.
>>>>>>
>>>>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>>>>> think this is a strong indicator that it is a good idea to do so. Of
>>>>>> course it might cause problems that I overlooked.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>>>>
>>>>>> Hi Achim,
>>>>>>>
>>>>>>> it is difficult to predict what changes warrant a discussion. I agree
>>>>>>> with you that I should have discussed this on the list. I talked to
>>>>>>> JB and he was positive so I did not expect any problems. Apparently I
>>>>>>> was wrong :-(
>>>>>>>
>>>>>>> The usage of bnd files for configuration of the imports and exports
>>>>>>> is a very concise replacement for the same configs in xml.
>>>>>>>
>>>>>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>>>>>> pom of each module. So basically you replace about 10-15 lines of xml
>>>>>>> with 0-5 lines in the bnd file.
>>>>>>>
>>>>>>> This does not break any functionality for users. For developers it
>>>>>>> just requires to put an empty bnd.bnd file into each module if it
>>>>>>> does not need special configs. Unfortunately it is not possible to
>>>>>>> define that it uses a bnd file if it is there  and is also happy if
>>>>>>> no such file is there. I plan to suggest this to the felix project as
>>>>>>> it would make this even easier to use.
>>>>>>>
>>>>>>> In what way do you see this as a breaking change? I made sure that
>>>>>>> all code still works and that all tests still pass. I also did manual
>>>>>>> tests of all the modules.
>>>>>>>
>>>>>>> So the only thing you need to do for a new module is to add this
>>>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>>>>> bnd file to configure your OSGi configs you can use the xml like
>>>>>>> before.
>>>>>>>
>>>>>>> So apart from my bad communication where I fully agree with you.. do
>>>>>>> you really  think this warrants a -1?
>>>>>>> Do you have any technical concerns?
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>>>>> <ma...@googlemail.com>>:
>>>>>>>
>>>>>>>      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
>>>>>>>
>>>>>>>      --
>>>>>>>
>>>>>>>      Apache Member
>>>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>      Committer &
>>>>>>>      Project Lead
>>>>>>>      blog <http://notizblog.nierbeck.de/>
>>>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>
>>>>>>>      Software Architect / Project Manager / Scrum Master
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi guys,

let me defuse the bomb ;)

1. Christian and I were sorry about our leak of communication. I'm as 
faulty as Christian, as he discussed about the change with me, I agreed, 
but I should have reminder to start a discussion on the mailing list. So 
another time, I'm sorry about that, and really apologize.
2. Now, Christian sent factual arguments about the change. Some can 
disagree, providing arguments, it's the way to do it.

However, guys, I know that I already pissed you bunch of time with that, 
but let me do it again:
- we are a team, an open source project is not an individual effort. So, 
we have to act as a team. Be always open minded, eager to discuss in a 
fair way.
- on the mailing list, please, keep a relax, cool (and maybe fun ;)) 
tone. We have different culture and background, and some words may sound 
different. Propose, never impose. Educate, never be harsh. Discuss, 
never order. Don't think you are better than other or the best, we are 
all noob and all proposal can make sense. Accept the mistake, because 
you will do a mistake one day ;)

I'm probably "old school minded", or it's maybe my rugby player way of 
thinking, but, relax, take a beer with the pal, and thinks will improve.

We do a great job in Karaf: it's not because we are the best, it's just 
because we do the job all together, always with the users, and listening 
proposal and arguments.

A smart and wise guy (especially developer) is able to change his mind 
bunch of time ;)

So guys, relax, and keep moving forward !

Regards
JB

On 02/11/2016 08:19 PM, Christian Schneider wrote:
> Hi Achim,
>
> thanks for your detailed description. I can assure you that I do not
> follow any evil plot like you seem to think. I will for sure not use
> gradle any time soon. I am quite happy with maven and am just trying to
> make our project better and the code more efficient. I also was not
> really sneaky by creating an issue up front and describing what I want
> to do. I just did not to also spawn a discussion on the list to make
> this more obvious. Please be assured that the only reason for this was
> my inherent impatience and good faith that JB would not have supported
> my change if he thought it would be a bad thing for the karaf community.
> So I was not really aware of doing something wrong at this time.
>
> Please also take into account that your build problem only happened on a
> new module you wanted to add and could be fixed by just adding the empty
> bnd.bnd file. So I think a -1 while possible was not really necessary. I
> think the better option would have been to bring the issue on the list
> and try to reach a consensus. I think in my whole apache history I never
> did a -1 on a commit.
>
> Do you insist on me taking back the commit now or would it be ok to
> first try to reach a consensus or if not possible do a vote? I will
> happily undo my commit if the outcome is to not do the change. On the
> other hand if we agree to do the change it would save me to shuffle the
> code back and  forth.
>
> If you insist on this I will undo the changes now. It is probably not
> possible to just undo the commit as there are quite a few commits in
> between. So it will be quite some manual work for me.
> I also hope that if you insist on me taking back the change now you are
> ok if I only undo the bnd file part of the commit and leave other
> changes like moving some common deps into the parent in place.
>
> Christian
>
>
> On 11.02.2016 17:06, Achim Nierbeck wrote:
>> Hi there,
>>
>> I'll stick to my
>>
>> -1
>>
>> Now the reasons for this:
>>
>> Even though the opposite has been proclaimed on the list, it did break
>> the
>> build for me. As without a bnd file the project isn't building
>> successfully, even though the information needed has been provided by the
>> pom.
>>
>> Second the usage of an extra bnd file is error prone, and I don't care
>> about removed lines of code, this is just not a justification.
>> Another thing why I opposed to extra bnd files. Only on Eclipse when
>> using
>> the bnd-tools project you have an extra editor available to use it. And
>> this only works for people using both, eclipse and the bnd-tools. All
>> others using a different tool chain are losing the benefit to see
>> everthing
>> in one go.
>> So basically people using IntelliJ or Netbeans (both tools to be know to
>> work far better with maven, then eclipse) are out of this. And I rather
>> don't rely on a proprietary tooling for this.
>>
>> So what's next after this? Just sneak the bnd-tools plugins into this
>> project for "supposedly" better support with eclipse and bnd-tools?
>> I don't think so. Our basis is still Maven and not Gradle, and this is
>> because we have a big user-base that feels very comfortable with it.
>> Using the declarations in the pom has been working nicely and if nothing
>> needs to be done one just needs to add those 4 lines for the usage of the
>> maven-bundle-plugin. No extra file needed, everything is in one place and
>> is in line with all other Karaf projects.
>> Actually this is one of the reasons I removed those bnd files from the
>> pax-web project long time ago, because all those project related
>> information are in one place now, instead of scattered around the
>> project.
>>
>> Third, and this does outweigh everything else. Christian tried to provide
>> evidence with this move and now argues this way everything is better for
>> us.
>> At this point I can't accept this. I don't think this is the way our
>> community works and surely this isn't the way we work together on our
>> sources. At least
>> this has been my understanding of a successful project.
>> If I'm wrong on this and everybody can do as he likes, I guess I need
>> think
>> about the consequences.
>>
>> regards, Achim
>>
>>
>>
>>
>> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>
>>> I see valid arguments here, and I keep my +1.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>>>
>>>> I also did a jira issue that explains the change.
>>>> https://issues.apache.org/jira/browse/KARAF-4300
>>>>
>>>> To show the advantage let me compare one of the old configs to the new
>>>> one:
>>>> http://apaste.info/gC5
>>>>
>>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
>>>> file.
>>>> The syntax is basically the same
>>>> as in xml just without the brackets. The big advantage is that we can
>>>> leave out the boilerplate xml that maven
>>>> needs to redefine a plugin.
>>>>
>>>> So I think the change to bnd files makes a lot of sense. I also did
>>>> this
>>>> change in Aries a long time ago.
>>>> Btw. I also added API baselining in this change which helps us when do
>>>> changes on the API.
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 11.02.2016 14:21, Christian Schneider wrote:
>>>>
>>>>> As further reference. This is the commit where I did the change:
>>>>>
>>>>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>>>
>>>>>
>>>>>
>>>>> As you can see I added 108 lines and removed 753.
>>>>>
>>>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>>>> think this is a strong indicator that it is a good idea to do so. Of
>>>>> course it might cause problems that I overlooked.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>>>
>>>>>> Hi Achim,
>>>>>>
>>>>>> it is difficult to predict what changes warrant a discussion. I agree
>>>>>> with you that I should have discussed this on the list. I talked to
>>>>>> JB and he was positive so I did not expect any problems. Apparently I
>>>>>> was wrong :-(
>>>>>>
>>>>>> The usage of bnd files for configuration of the imports and exports
>>>>>> is a very concise replacement for the same configs in xml.
>>>>>>
>>>>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>>>>> pom of each module. So basically you replace about 10-15 lines of xml
>>>>>> with 0-5 lines in the bnd file.
>>>>>>
>>>>>> This does not break any functionality for users. For developers it
>>>>>> just requires to put an empty bnd.bnd file into each module if it
>>>>>> does not need special configs. Unfortunately it is not possible to
>>>>>> define that it uses a bnd file if it is there  and is also happy if
>>>>>> no such file is there. I plan to suggest this to the felix project as
>>>>>> it would make this even easier to use.
>>>>>>
>>>>>> In what way do you see this as a breaking change? I made sure that
>>>>>> all code still works and that all tests still pass. I also did manual
>>>>>> tests of all the modules.
>>>>>>
>>>>>> So the only thing you need to do for a new module is to add this
>>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>>>> bnd file to configure your OSGi configs you can use the xml like
>>>>>> before.
>>>>>>
>>>>>> So apart from my bad communication where I fully agree with you.. do
>>>>>> you really  think this warrants a -1?
>>>>>> Do you have any technical concerns?
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>>>> <ma...@googlemail.com>>:
>>>>>>
>>>>>>      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
>>>>>>
>>>>>>      --
>>>>>>
>>>>>>      Apache Member
>>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>      Committer &
>>>>>>      Project Lead
>>>>>>      blog <http://notizblog.nierbeck.de/>
>>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>
>>>>>>      Software Architect / Project Manager / Scrum Master
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>>
>>>>> --
>>>>> 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
>>>
>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: bnd files in Decanter Project

[David Daniel <da...@gmail.com>]

My 2 cents as another person who doesn't contribute but cares deeply about
karaf.

On Thu, Feb 11, 2016 at 5:41 PM, Achim Nierbeck <bc...@googlemail.com>
wrote:

> Hi Milan,
>
> You are right about lot of things, just this kind of discussion should have
> been before the change.
>

You are correct and Christian apologized in a number of different emails.
This is definitely something that should have been brought up but and
codified in a coding style guide somewhere but it can still be discussed
and worked out now in a peaceful manner.  I don't think there was any
malice involved.  You both have helped me on a number of occasions and have
contributed a large amount of time to a common good.  In my book you both
seem like good people with good intentions for karaf.


> Technically I can see some advantages of the extra file, on the other hand
> I prefer to have all project related information in one file. Try to
> explain a newbie that he now has to do a context switch and change over to
> another file for the OSGi stuff, while all other project related
> information, especially dependencies and versions are within the pom.
>

I tend to agree but I think this is kinda a slippery slope.  It is not just
maven where you can have osgi information.  You can include it in
attributes.  You can declare your exports in package.java from Tim below.

"Export-Package: can be inferred from the presence of the OSGi Version
annotation on the package-info.java. See the -exportcontents instruction
and the ${packages} macro for details of how to do this."

It can be in bnd files or xml files.  Without some kind of agreement on
where things should be people tend to have their own preferences.  If you
think this is bad try coming to an agreement on a scala project :)  I think
there was a legitimate feeling that he was improving the project to the
extent that he took hours to make the changes.  He then offered to roll
them back when he found out that it was not unanimously thought to be a
good change.  Whether the is agreement on his opinions or not it is at
least a grey area and no malice should be assumed.


Another benefit I see in having this kind of information in the pom, if you
> search for an dependency on maven central you usually can also take a look
> at the pom.
> There I often take a look at it, to check is it a valid OSGi bundle, what
> did the people to build it add as extras to the pom to make sure of it.
> This will be lost when you have it in the bnd file which isn't a versioned
> artifact.
>
> But as I'm obviously the only stupid to actually voice his concern about
> HOW this change was made I'll give up.
>

You are not the only person to voice your feelings as someone else seconded
your -1 but I don't think it is about giving up.  That seems like walking
away with hard feelings on something you seem to feel strongly about.  I
tend to like Christians way of doing things as it is more similar to what I
do on my projects but think things should not change from the way they were
as I can understand not everyone feels the same and without consensus the
way things were should be the default.


>
> So it looks a lot like everybody can just do as he likes, this is the
> quintessence I get from this.
>

I think this is not what anyone was trying to get across.


>
> So no need to revert the changes.
>
> sent from mobile device
> Am 11.02.2016 11:19 nachm. schrieb "Milen Dyankov" <milendyankov@gmail.com
> >:
>
> > Guys,
> >
> > Allow me to provide my 2 cents in this discussion.
> >
> > One - I think we have more than enough arogancie and blame games in the
> > OSGi community. We really don't need more of those. It would be nice if
> > everyone could remain calm and watch their language even if they have a
> > point as far as the facts are concern. Let's not assume bad intentions
> just
> > because of frustration with something. People make mistakes and wrong
> > decisions. And we are all people! Luckily it's only software in this
> case,
> > no one gets hurt (physically) and things are easy to fix. Let us be nice
> to
> > each other. Please!
> >
> > Two - for me personally it doesn't make huge difference if the
> information
> > is in the POM or in the bnd file. You, the guys working on the project
> the
> > most, should decide on that. However here are few things to consider:
> >  - It is true that using bnd files reduces the size of the POMs which is
> > particularly important if you have complex multi-module projects
> >  - Both maven plugins available up to date are using bnd (not to be
> > confused with bnd-tools) under the hood and bnd.bnd files are the default
> > way to provide instructions to bnd. Personally I don't understand why
> > someone decided to have this in POM in first place while creating the
> > maven-bundle-plugin.
> >  - The new bnd-maven-plugin (which I see people using more and more
> often)
> > requires you to have all the instructions in bnd.bnd file. Moreover it is
> > able to process bnd.bnd from parent projects which allows you to
> completely
> > skip those in child projects if you don't need to.
> >
> > Don't get me wrong, I'm not suggesting yet another approach. Just
> pointing
> > out there are options out there that could be discussed in civilized and
> > polite way!
> >
> > Best,
> > Milen
> >
> >
> >
> >
> >
> > On Thu, Feb 11, 2016 at 9:43 PM, Achim Nierbeck <bcanhome@googlemail.com
> >
> > wrote:
> >
> > > Hi Christian,
> > >
> > > I don't think you seem to follow an evil plot, it's just you don't seem
> > to
> > > think ahead and take yourself to important.
> > > This discussion about bnd.file or not bnd.file should have been done
> > before
> > > you provided evidence.
> > > A discussion on IRC is as you should be aware of not a valid
> discussion.
> > So
> > > if it didn't happen on the mailinglist, it didn't happen.
> > >
> > > At this point I don't get why you now try to turn your "jumping the
> gun"
> > > into me being at fault.
> > >
> > > The only change I'm arguing about is the extra bnd.file all other build
> > > improvements are regular changes, which I'm not arguing about.
> > > Again for me an extra configuration file isn't of any value compared to
> > the
> > > configuration contained in the pom.
> > >
> > > So this isn't about me insisting you to change everything back, the
> issue
> > > here is that you impose what you think is best on everybody else.
> > >
> > > Achim
> > >
> > >
> > >
> > > 2016-02-11 20:19 GMT+01:00 Christian Schneider <
> chris@die-schneider.net
> > >:
> > >
> > > > Hi Achim,
> > > >
> > > > thanks for your detailed description. I can assure you that I do not
> > > > follow any evil plot like you seem to think. I will for sure not use
> > > gradle
> > > > any time soon. I am quite happy with maven and am just trying to make
> > our
> > > > project better and the code more efficient. I also was not really
> > sneaky
> > > by
> > > > creating an issue up front and describing what I want to do. I just
> did
> > > not
> > > > to also spawn a discussion on the list to make this more obvious.
> > Please
> > > be
> > > > assured that the only reason for this was my inherent impatience and
> > good
> > > > faith that JB would not have supported my change if he thought it
> would
> > > be
> > > > a bad thing for the karaf community. So I was not really aware of
> doing
> > > > something wrong at this time.
> > > >
> > > > Please also take into account that your build problem only happened
> on
> > a
> > > > new module you wanted to add and could be fixed by just adding the
> > empty
> > > > bnd.bnd file. So I think a -1 while possible was not really
> necessary.
> > I
> > > > think the better option would have been to bring the issue on the
> list
> > > and
> > > > try to reach a consensus. I think in my whole apache history I never
> > did
> > > a
> > > > -1 on a commit.
> > > >
> > > > Do you insist on me taking back the commit now or would it be ok to
> > first
> > > > try to reach a consensus or if not possible do a vote? I will happily
> > > undo
> > > > my commit if the outcome is to not do the change. On the other hand
> if
> > we
> > > > agree to do the change it would save me to shuffle the code back and
> > > forth.
> > > >
> > > > If you insist on this I will undo the changes now. It is probably not
> > > > possible to just undo the commit as there are quite a few commits in
> > > > between. So it will be quite some manual work for me.
> > > > I also hope that if you insist on me taking back the change now you
> are
> > > ok
> > > > if I only undo the bnd file part of the commit and leave other
> changes
> > > like
> > > > moving some common deps into the parent in place.
> > > >
> > > > Christian
> > > >
> > > >
> > > >
> > > > On 11.02.2016 17:06, Achim Nierbeck wrote:
> > > >
> > > >> Hi there,
> > > >>
> > > >> I'll stick to my
> > > >>
> > > >> -1
> > > >>
> > > >> Now the reasons for this:
> > > >>
> > > >> Even though the opposite has been proclaimed on the list, it did
> break
> > > the
> > > >> build for me. As without a bnd file the project isn't building
> > > >> successfully, even though the information needed has been provided
> by
> > > the
> > > >> pom.
> > > >>
> > > >> Second the usage of an extra bnd file is error prone, and I don't
> care
> > > >> about removed lines of code, this is just not a justification.
> > > >> Another thing why I opposed to extra bnd files. Only on Eclipse when
> > > using
> > > >> the bnd-tools project you have an extra editor available to use it.
> > And
> > > >> this only works for people using both, eclipse and the bnd-tools.
> All
> > > >> others using a different tool chain are losing the benefit to see
> > > >> everthing
> > > >> in one go.
> > > >> So basically people using IntelliJ or Netbeans (both tools to be
> know
> > to
> > > >> work far better with maven, then eclipse) are out of this. And I
> > rather
> > > >> don't rely on a proprietary tooling for this.
> > > >>
> > > >> So what's next after this? Just sneak the bnd-tools plugins into
> this
> > > >> project for "supposedly" better support with eclipse and bnd-tools?
> > > >> I don't think so. Our basis is still Maven and not Gradle, and this
> is
> > > >> because we have a big user-base that feels very comfortable with it.
> > > >> Using the declarations in the pom has been working nicely and if
> > nothing
> > > >> needs to be done one just needs to add those 4 lines for the usage
> of
> > > the
> > > >> maven-bundle-plugin. No extra file needed, everything is in one
> place
> > > and
> > > >> is in line with all other Karaf projects.
> > > >> Actually this is one of the reasons I removed those bnd files from
> the
> > > >> pax-web project long time ago, because all those project related
> > > >> information are in one place now, instead of scattered around the
> > > project.
> > > >>
> > > >> Third, and this does outweigh everything else. Christian tried to
> > > provide
> > > >> evidence with this move and now argues this way everything is better
> > for
> > > >> us.
> > > >> At this point I can't accept this. I don't think this is the way our
> > > >> community works and surely this isn't the way we work together on
> our
> > > >> sources. At least
> > > >> this has been my understanding of a successful project.
> > > >> If I'm wrong on this and everybody can do as he likes, I guess I
> need
> > > >> think
> > > >> about the consequences.
> > > >>
> > > >> regards, Achim
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> > > >>
> > > >> I see valid arguments here, and I keep my +1.
> > > >>>
> > > >>> Regards
> > > >>> JB
> > > >>>
> > > >>>
> > > >>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
> > > >>>
> > > >>> I also did a jira issue that explains the change.
> > > >>>> https://issues.apache.org/jira/browse/KARAF-4300
> > > >>>>
> > > >>>> To show the advantage let me compare one of the old configs to the
> > new
> > > >>>> one:
> > > >>>> http://apaste.info/gC5
> > > >>>>
> > > >>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
> > > file.
> > > >>>> The syntax is basically the same
> > > >>>> as in xml just without the brackets. The big advantage is that we
> > can
> > > >>>> leave out the boilerplate xml that maven
> > > >>>> needs to redefine a plugin.
> > > >>>>
> > > >>>> So I think the change to bnd files makes a lot of sense. I also
> did
> > > this
> > > >>>> change in Aries a long time ago.
> > > >>>> Btw. I also added API baselining in this change which helps us
> when
> > do
> > > >>>> changes on the API.
> > > >>>>
> > > >>>> Christian
> > > >>>>
> > > >>>>
> > > >>>> On 11.02.2016 14:21, Christian Schneider wrote:
> > > >>>>
> > > >>>> As further reference. This is the commit where I did the change:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > >
> >
> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
> > > >>>>>
> > > >>>>>
> > > >>>>> As you can see I added 108 lines and removed 753.
> > > >>>>>
> > > >>>>> That means the usage of bnd files saves us about 640 lines of
> xml.
> > I
> > > >>>>> think this is a strong indicator that it is a good idea to do so.
> > Of
> > > >>>>> course it might cause problems that I overlooked.
> > > >>>>>
> > > >>>>> Christian
> > > >>>>>
> > > >>>>> On 11.02.2016 13:57, Christian Schneider wrote:
> > > >>>>>
> > > >>>>> Hi Achim,
> > > >>>>>>
> > > >>>>>> it is difficult to predict what changes warrant a discussion. I
> > > agree
> > > >>>>>> with you that I should have discussed this on the list. I talked
> > to
> > > >>>>>> JB and he was positive so I did not expect any problems.
> > Apparently
> > > I
> > > >>>>>> was wrong :-(
> > > >>>>>>
> > > >>>>>> The usage of bnd files for configuration of the imports and
> > exports
> > > >>>>>> is a very concise replacement for the same configs in xml.
> > > >>>>>>
> > > >>>>>> The big advantage is that you can omit the maven-bundle-plugin
> in
> > > the
> > > >>>>>> pom of each module. So basically you replace about 10-15 lines
> of
> > > xml
> > > >>>>>> with 0-5 lines in the bnd file.
> > > >>>>>>
> > > >>>>>> This does not break any functionality for users. For developers
> it
> > > >>>>>> just requires to put an empty bnd.bnd file into each module if
> it
> > > >>>>>> does not need special configs. Unfortunately it is not possible
> to
> > > >>>>>> define that it uses a bnd file if it is there  and is also happy
> > if
> > > >>>>>> no such file is there. I plan to suggest this to the felix
> project
> > > as
> > > >>>>>> it would make this even easier to use.
> > > >>>>>>
> > > >>>>>> In what way do you see this as a breaking change? I made sure
> that
> > > >>>>>> all code still works and that all tests still pass. I also did
> > > manual
> > > >>>>>> tests of all the modules.
> > > >>>>>>
> > > >>>>>> So the only thing you need to do for a new module is to add this
> > > >>>>>> empty bnd.bnd file and you are fine. If you do not want to use
> the
> > > >>>>>> bnd file to configure your OSGi configs you can use the xml like
> > > >>>>>> before.
> > > >>>>>>
> > > >>>>>> So apart from my bad communication where I fully agree with
> you..
> > do
> > > >>>>>> you really  think this warrants a -1?
> > > >>>>>> Do you have any technical concerns?
> > > >>>>>>
> > > >>>>>> Christian
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <
> bcanhome@googlemail.com
> > > >>>>>> <ma...@googlemail.com>>:
> > > >>>>>>
> > > >>>>>>      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
> > > >>>>>>
> > > >>>>>>      --
> > > >>>>>>
> > > >>>>>>      Apache Member
> > > >>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > > >>>>>>      OPS4J Pax Web <
> http://wiki.ops4j.org/display/paxweb/Pax+Web/
> > >
> > > >>>>>>      Committer &
> > > >>>>>>      Project Lead
> > > >>>>>>      blog <http://notizblog.nierbeck.de/>
> > > >>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> > > >>>>>>
> > > >>>>>>      Software Architect / Project Manager / Scrum Master
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> --
> > > >>>>>> 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
> > > >>>>>>
> > > >>>>>> --
> > > >>>>> 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
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > > --
> > > > Christian Schneider
> > > > http://www.liquid-reality.de
> > > >
> > > > Open Source Architect
> > > > http://www.talend.com
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Apache Member
> > > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer
> > &
> > > Project Lead
> > > blog <http://notizblog.nierbeck.de/>
> > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> > >
> > > Software Architect / Project Manager / Scrum Master
> > >
> >
> >
> >
> > --
> > http://about.me/milen
> >
>

Re: bnd files in Decanter Project

[Achim Nierbeck <bc...@googlemail.com>]

Hi Milan,

You are right about lot of things, just this kind of discussion should have
been before the change.
Technically I can see some advantages of the extra file, on the other hand
I prefer to have all project related information in one file. Try to
explain a newbie that he now has to do a context switch and change over to
another file for the OSGi stuff, while all other project related
information, especially dependencies and versions are within the pom.
Another benefit I see in having this kind of information in the pom, if you
search for an dependency on maven central you usually can also take a look
at the pom.
There I often take a look at it, to check is it a valid OSGi bundle, what
did the people to build it add as extras to the pom to make sure of it.
This will be lost when you have it in the bnd file which isn't a versioned
artifact.

But as I'm obviously the only stupid to actually voice his concern about
HOW this change was made I'll give up.

So it looks a lot like everybody can just do as he likes, this is the
quintessence I get from this.

So no need to revert the changes.

sent from mobile device
Am 11.02.2016 11:19 nachm. schrieb "Milen Dyankov" <mi...@gmail.com>:

> Guys,
>
> Allow me to provide my 2 cents in this discussion.
>
> One - I think we have more than enough arogancie and blame games in the
> OSGi community. We really don't need more of those. It would be nice if
> everyone could remain calm and watch their language even if they have a
> point as far as the facts are concern. Let's not assume bad intentions just
> because of frustration with something. People make mistakes and wrong
> decisions. And we are all people! Luckily it's only software in this case,
> no one gets hurt (physically) and things are easy to fix. Let us be nice to
> each other. Please!
>
> Two - for me personally it doesn't make huge difference if the information
> is in the POM or in the bnd file. You, the guys working on the project the
> most, should decide on that. However here are few things to consider:
>  - It is true that using bnd files reduces the size of the POMs which is
> particularly important if you have complex multi-module projects
>  - Both maven plugins available up to date are using bnd (not to be
> confused with bnd-tools) under the hood and bnd.bnd files are the default
> way to provide instructions to bnd. Personally I don't understand why
> someone decided to have this in POM in first place while creating the
> maven-bundle-plugin.
>  - The new bnd-maven-plugin (which I see people using more and more often)
> requires you to have all the instructions in bnd.bnd file. Moreover it is
> able to process bnd.bnd from parent projects which allows you to completely
> skip those in child projects if you don't need to.
>
> Don't get me wrong, I'm not suggesting yet another approach. Just pointing
> out there are options out there that could be discussed in civilized and
> polite way!
>
> Best,
> Milen
>
>
>
>
>
> On Thu, Feb 11, 2016 at 9:43 PM, Achim Nierbeck <bc...@googlemail.com>
> wrote:
>
> > Hi Christian,
> >
> > I don't think you seem to follow an evil plot, it's just you don't seem
> to
> > think ahead and take yourself to important.
> > This discussion about bnd.file or not bnd.file should have been done
> before
> > you provided evidence.
> > A discussion on IRC is as you should be aware of not a valid discussion.
> So
> > if it didn't happen on the mailinglist, it didn't happen.
> >
> > At this point I don't get why you now try to turn your "jumping the gun"
> > into me being at fault.
> >
> > The only change I'm arguing about is the extra bnd.file all other build
> > improvements are regular changes, which I'm not arguing about.
> > Again for me an extra configuration file isn't of any value compared to
> the
> > configuration contained in the pom.
> >
> > So this isn't about me insisting you to change everything back, the issue
> > here is that you impose what you think is best on everybody else.
> >
> > Achim
> >
> >
> >
> > 2016-02-11 20:19 GMT+01:00 Christian Schneider <chris@die-schneider.net
> >:
> >
> > > Hi Achim,
> > >
> > > thanks for your detailed description. I can assure you that I do not
> > > follow any evil plot like you seem to think. I will for sure not use
> > gradle
> > > any time soon. I am quite happy with maven and am just trying to make
> our
> > > project better and the code more efficient. I also was not really
> sneaky
> > by
> > > creating an issue up front and describing what I want to do. I just did
> > not
> > > to also spawn a discussion on the list to make this more obvious.
> Please
> > be
> > > assured that the only reason for this was my inherent impatience and
> good
> > > faith that JB would not have supported my change if he thought it would
> > be
> > > a bad thing for the karaf community. So I was not really aware of doing
> > > something wrong at this time.
> > >
> > > Please also take into account that your build problem only happened on
> a
> > > new module you wanted to add and could be fixed by just adding the
> empty
> > > bnd.bnd file. So I think a -1 while possible was not really necessary.
> I
> > > think the better option would have been to bring the issue on the list
> > and
> > > try to reach a consensus. I think in my whole apache history I never
> did
> > a
> > > -1 on a commit.
> > >
> > > Do you insist on me taking back the commit now or would it be ok to
> first
> > > try to reach a consensus or if not possible do a vote? I will happily
> > undo
> > > my commit if the outcome is to not do the change. On the other hand if
> we
> > > agree to do the change it would save me to shuffle the code back and
> > forth.
> > >
> > > If you insist on this I will undo the changes now. It is probably not
> > > possible to just undo the commit as there are quite a few commits in
> > > between. So it will be quite some manual work for me.
> > > I also hope that if you insist on me taking back the change now you are
> > ok
> > > if I only undo the bnd file part of the commit and leave other changes
> > like
> > > moving some common deps into the parent in place.
> > >
> > > Christian
> > >
> > >
> > >
> > > On 11.02.2016 17:06, Achim Nierbeck wrote:
> > >
> > >> Hi there,
> > >>
> > >> I'll stick to my
> > >>
> > >> -1
> > >>
> > >> Now the reasons for this:
> > >>
> > >> Even though the opposite has been proclaimed on the list, it did break
> > the
> > >> build for me. As without a bnd file the project isn't building
> > >> successfully, even though the information needed has been provided by
> > the
> > >> pom.
> > >>
> > >> Second the usage of an extra bnd file is error prone, and I don't care
> > >> about removed lines of code, this is just not a justification.
> > >> Another thing why I opposed to extra bnd files. Only on Eclipse when
> > using
> > >> the bnd-tools project you have an extra editor available to use it.
> And
> > >> this only works for people using both, eclipse and the bnd-tools. All
> > >> others using a different tool chain are losing the benefit to see
> > >> everthing
> > >> in one go.
> > >> So basically people using IntelliJ or Netbeans (both tools to be know
> to
> > >> work far better with maven, then eclipse) are out of this. And I
> rather
> > >> don't rely on a proprietary tooling for this.
> > >>
> > >> So what's next after this? Just sneak the bnd-tools plugins into this
> > >> project for "supposedly" better support with eclipse and bnd-tools?
> > >> I don't think so. Our basis is still Maven and not Gradle, and this is
> > >> because we have a big user-base that feels very comfortable with it.
> > >> Using the declarations in the pom has been working nicely and if
> nothing
> > >> needs to be done one just needs to add those 4 lines for the usage of
> > the
> > >> maven-bundle-plugin. No extra file needed, everything is in one place
> > and
> > >> is in line with all other Karaf projects.
> > >> Actually this is one of the reasons I removed those bnd files from the
> > >> pax-web project long time ago, because all those project related
> > >> information are in one place now, instead of scattered around the
> > project.
> > >>
> > >> Third, and this does outweigh everything else. Christian tried to
> > provide
> > >> evidence with this move and now argues this way everything is better
> for
> > >> us.
> > >> At this point I can't accept this. I don't think this is the way our
> > >> community works and surely this isn't the way we work together on our
> > >> sources. At least
> > >> this has been my understanding of a successful project.
> > >> If I'm wrong on this and everybody can do as he likes, I guess I need
> > >> think
> > >> about the consequences.
> > >>
> > >> regards, Achim
> > >>
> > >>
> > >>
> > >>
> > >> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> > >>
> > >> I see valid arguments here, and I keep my +1.
> > >>>
> > >>> Regards
> > >>> JB
> > >>>
> > >>>
> > >>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
> > >>>
> > >>> I also did a jira issue that explains the change.
> > >>>> https://issues.apache.org/jira/browse/KARAF-4300
> > >>>>
> > >>>> To show the advantage let me compare one of the old configs to the
> new
> > >>>> one:
> > >>>> http://apaste.info/gC5
> > >>>>
> > >>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
> > file.
> > >>>> The syntax is basically the same
> > >>>> as in xml just without the brackets. The big advantage is that we
> can
> > >>>> leave out the boilerplate xml that maven
> > >>>> needs to redefine a plugin.
> > >>>>
> > >>>> So I think the change to bnd files makes a lot of sense. I also did
> > this
> > >>>> change in Aries a long time ago.
> > >>>> Btw. I also added API baselining in this change which helps us when
> do
> > >>>> changes on the API.
> > >>>>
> > >>>> Christian
> > >>>>
> > >>>>
> > >>>> On 11.02.2016 14:21, Christian Schneider wrote:
> > >>>>
> > >>>> As further reference. This is the commit where I did the change:
> > >>>>>
> > >>>>>
> > >>>>>
> >
> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
> > >>>>>
> > >>>>>
> > >>>>> As you can see I added 108 lines and removed 753.
> > >>>>>
> > >>>>> That means the usage of bnd files saves us about 640 lines of xml.
> I
> > >>>>> think this is a strong indicator that it is a good idea to do so.
> Of
> > >>>>> course it might cause problems that I overlooked.
> > >>>>>
> > >>>>> Christian
> > >>>>>
> > >>>>> On 11.02.2016 13:57, Christian Schneider wrote:
> > >>>>>
> > >>>>> Hi Achim,
> > >>>>>>
> > >>>>>> it is difficult to predict what changes warrant a discussion. I
> > agree
> > >>>>>> with you that I should have discussed this on the list. I talked
> to
> > >>>>>> JB and he was positive so I did not expect any problems.
> Apparently
> > I
> > >>>>>> was wrong :-(
> > >>>>>>
> > >>>>>> The usage of bnd files for configuration of the imports and
> exports
> > >>>>>> is a very concise replacement for the same configs in xml.
> > >>>>>>
> > >>>>>> The big advantage is that you can omit the maven-bundle-plugin in
> > the
> > >>>>>> pom of each module. So basically you replace about 10-15 lines of
> > xml
> > >>>>>> with 0-5 lines in the bnd file.
> > >>>>>>
> > >>>>>> This does not break any functionality for users. For developers it
> > >>>>>> just requires to put an empty bnd.bnd file into each module if it
> > >>>>>> does not need special configs. Unfortunately it is not possible to
> > >>>>>> define that it uses a bnd file if it is there  and is also happy
> if
> > >>>>>> no such file is there. I plan to suggest this to the felix project
> > as
> > >>>>>> it would make this even easier to use.
> > >>>>>>
> > >>>>>> In what way do you see this as a breaking change? I made sure that
> > >>>>>> all code still works and that all tests still pass. I also did
> > manual
> > >>>>>> tests of all the modules.
> > >>>>>>
> > >>>>>> So the only thing you need to do for a new module is to add this
> > >>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
> > >>>>>> bnd file to configure your OSGi configs you can use the xml like
> > >>>>>> before.
> > >>>>>>
> > >>>>>> So apart from my bad communication where I fully agree with you..
> do
> > >>>>>> you really  think this warrants a -1?
> > >>>>>> Do you have any technical concerns?
> > >>>>>>
> > >>>>>> Christian
> > >>>>>>
> > >>>>>>
> > >>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
> > >>>>>> <ma...@googlemail.com>>:
> > >>>>>>
> > >>>>>>      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
> > >>>>>>
> > >>>>>>      --
> > >>>>>>
> > >>>>>>      Apache Member
> > >>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > >>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/
> >
> > >>>>>>      Committer &
> > >>>>>>      Project Lead
> > >>>>>>      blog <http://notizblog.nierbeck.de/>
> > >>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> > >>>>>>
> > >>>>>>      Software Architect / Project Manager / Scrum Master
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> --
> > >>>>>> 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
> > >>>>>>
> > >>>>>> --
> > >>>>> 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
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Open Source Architect
> > > http://www.talend.com
> > >
> > >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
> &
> > Project Lead
> > blog <http://notizblog.nierbeck.de/>
> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >
> > Software Architect / Project Manager / Scrum Master
> >
>
>
>
> --
> http://about.me/milen
>

Re: bnd files in Decanter Project

[Milen Dyankov <mi...@gmail.com>]

Guys,

Allow me to provide my 2 cents in this discussion.

One - I think we have more than enough arogancie and blame games in the
OSGi community. We really don't need more of those. It would be nice if
everyone could remain calm and watch their language even if they have a
point as far as the facts are concern. Let's not assume bad intentions just
because of frustration with something. People make mistakes and wrong
decisions. And we are all people! Luckily it's only software in this case,
no one gets hurt (physically) and things are easy to fix. Let us be nice to
each other. Please!

Two - for me personally it doesn't make huge difference if the information
is in the POM or in the bnd file. You, the guys working on the project the
most, should decide on that. However here are few things to consider:
 - It is true that using bnd files reduces the size of the POMs which is
particularly important if you have complex multi-module projects
 - Both maven plugins available up to date are using bnd (not to be
confused with bnd-tools) under the hood and bnd.bnd files are the default
way to provide instructions to bnd. Personally I don't understand why
someone decided to have this in POM in first place while creating the
maven-bundle-plugin.
 - The new bnd-maven-plugin (which I see people using more and more often)
requires you to have all the instructions in bnd.bnd file. Moreover it is
able to process bnd.bnd from parent projects which allows you to completely
skip those in child projects if you don't need to.

Don't get me wrong, I'm not suggesting yet another approach. Just pointing
out there are options out there that could be discussed in civilized and
polite way!

Best,
Milen





On Thu, Feb 11, 2016 at 9:43 PM, Achim Nierbeck <bc...@googlemail.com>
wrote:

> Hi Christian,
>
> I don't think you seem to follow an evil plot, it's just you don't seem to
> think ahead and take yourself to important.
> This discussion about bnd.file or not bnd.file should have been done before
> you provided evidence.
> A discussion on IRC is as you should be aware of not a valid discussion. So
> if it didn't happen on the mailinglist, it didn't happen.
>
> At this point I don't get why you now try to turn your "jumping the gun"
> into me being at fault.
>
> The only change I'm arguing about is the extra bnd.file all other build
> improvements are regular changes, which I'm not arguing about.
> Again for me an extra configuration file isn't of any value compared to the
> configuration contained in the pom.
>
> So this isn't about me insisting you to change everything back, the issue
> here is that you impose what you think is best on everybody else.
>
> Achim
>
>
>
> 2016-02-11 20:19 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
> > Hi Achim,
> >
> > thanks for your detailed description. I can assure you that I do not
> > follow any evil plot like you seem to think. I will for sure not use
> gradle
> > any time soon. I am quite happy with maven and am just trying to make our
> > project better and the code more efficient. I also was not really sneaky
> by
> > creating an issue up front and describing what I want to do. I just did
> not
> > to also spawn a discussion on the list to make this more obvious. Please
> be
> > assured that the only reason for this was my inherent impatience and good
> > faith that JB would not have supported my change if he thought it would
> be
> > a bad thing for the karaf community. So I was not really aware of doing
> > something wrong at this time.
> >
> > Please also take into account that your build problem only happened on a
> > new module you wanted to add and could be fixed by just adding the empty
> > bnd.bnd file. So I think a -1 while possible was not really necessary. I
> > think the better option would have been to bring the issue on the list
> and
> > try to reach a consensus. I think in my whole apache history I never did
> a
> > -1 on a commit.
> >
> > Do you insist on me taking back the commit now or would it be ok to first
> > try to reach a consensus or if not possible do a vote? I will happily
> undo
> > my commit if the outcome is to not do the change. On the other hand if we
> > agree to do the change it would save me to shuffle the code back and
> forth.
> >
> > If you insist on this I will undo the changes now. It is probably not
> > possible to just undo the commit as there are quite a few commits in
> > between. So it will be quite some manual work for me.
> > I also hope that if you insist on me taking back the change now you are
> ok
> > if I only undo the bnd file part of the commit and leave other changes
> like
> > moving some common deps into the parent in place.
> >
> > Christian
> >
> >
> >
> > On 11.02.2016 17:06, Achim Nierbeck wrote:
> >
> >> Hi there,
> >>
> >> I'll stick to my
> >>
> >> -1
> >>
> >> Now the reasons for this:
> >>
> >> Even though the opposite has been proclaimed on the list, it did break
> the
> >> build for me. As without a bnd file the project isn't building
> >> successfully, even though the information needed has been provided by
> the
> >> pom.
> >>
> >> Second the usage of an extra bnd file is error prone, and I don't care
> >> about removed lines of code, this is just not a justification.
> >> Another thing why I opposed to extra bnd files. Only on Eclipse when
> using
> >> the bnd-tools project you have an extra editor available to use it. And
> >> this only works for people using both, eclipse and the bnd-tools. All
> >> others using a different tool chain are losing the benefit to see
> >> everthing
> >> in one go.
> >> So basically people using IntelliJ or Netbeans (both tools to be know to
> >> work far better with maven, then eclipse) are out of this. And I rather
> >> don't rely on a proprietary tooling for this.
> >>
> >> So what's next after this? Just sneak the bnd-tools plugins into this
> >> project for "supposedly" better support with eclipse and bnd-tools?
> >> I don't think so. Our basis is still Maven and not Gradle, and this is
> >> because we have a big user-base that feels very comfortable with it.
> >> Using the declarations in the pom has been working nicely and if nothing
> >> needs to be done one just needs to add those 4 lines for the usage of
> the
> >> maven-bundle-plugin. No extra file needed, everything is in one place
> and
> >> is in line with all other Karaf projects.
> >> Actually this is one of the reasons I removed those bnd files from the
> >> pax-web project long time ago, because all those project related
> >> information are in one place now, instead of scattered around the
> project.
> >>
> >> Third, and this does outweigh everything else. Christian tried to
> provide
> >> evidence with this move and now argues this way everything is better for
> >> us.
> >> At this point I can't accept this. I don't think this is the way our
> >> community works and surely this isn't the way we work together on our
> >> sources. At least
> >> this has been my understanding of a successful project.
> >> If I'm wrong on this and everybody can do as he likes, I guess I need
> >> think
> >> about the consequences.
> >>
> >> regards, Achim
> >>
> >>
> >>
> >>
> >> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >>
> >> I see valid arguments here, and I keep my +1.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
> >>>
> >>> I also did a jira issue that explains the change.
> >>>> https://issues.apache.org/jira/browse/KARAF-4300
> >>>>
> >>>> To show the advantage let me compare one of the old configs to the new
> >>>> one:
> >>>> http://apaste.info/gC5
> >>>>
> >>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
> file.
> >>>> The syntax is basically the same
> >>>> as in xml just without the brackets. The big advantage is that we can
> >>>> leave out the boilerplate xml that maven
> >>>> needs to redefine a plugin.
> >>>>
> >>>> So I think the change to bnd files makes a lot of sense. I also did
> this
> >>>> change in Aries a long time ago.
> >>>> Btw. I also added API baselining in this change which helps us when do
> >>>> changes on the API.
> >>>>
> >>>> Christian
> >>>>
> >>>>
> >>>> On 11.02.2016 14:21, Christian Schneider wrote:
> >>>>
> >>>> As further reference. This is the commit where I did the change:
> >>>>>
> >>>>>
> >>>>>
> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
> >>>>>
> >>>>>
> >>>>> As you can see I added 108 lines and removed 753.
> >>>>>
> >>>>> That means the usage of bnd files saves us about 640 lines of xml. I
> >>>>> think this is a strong indicator that it is a good idea to do so. Of
> >>>>> course it might cause problems that I overlooked.
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> On 11.02.2016 13:57, Christian Schneider wrote:
> >>>>>
> >>>>> Hi Achim,
> >>>>>>
> >>>>>> it is difficult to predict what changes warrant a discussion. I
> agree
> >>>>>> with you that I should have discussed this on the list. I talked to
> >>>>>> JB and he was positive so I did not expect any problems. Apparently
> I
> >>>>>> was wrong :-(
> >>>>>>
> >>>>>> The usage of bnd files for configuration of the imports and exports
> >>>>>> is a very concise replacement for the same configs in xml.
> >>>>>>
> >>>>>> The big advantage is that you can omit the maven-bundle-plugin in
> the
> >>>>>> pom of each module. So basically you replace about 10-15 lines of
> xml
> >>>>>> with 0-5 lines in the bnd file.
> >>>>>>
> >>>>>> This does not break any functionality for users. For developers it
> >>>>>> just requires to put an empty bnd.bnd file into each module if it
> >>>>>> does not need special configs. Unfortunately it is not possible to
> >>>>>> define that it uses a bnd file if it is there  and is also happy if
> >>>>>> no such file is there. I plan to suggest this to the felix project
> as
> >>>>>> it would make this even easier to use.
> >>>>>>
> >>>>>> In what way do you see this as a breaking change? I made sure that
> >>>>>> all code still works and that all tests still pass. I also did
> manual
> >>>>>> tests of all the modules.
> >>>>>>
> >>>>>> So the only thing you need to do for a new module is to add this
> >>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
> >>>>>> bnd file to configure your OSGi configs you can use the xml like
> >>>>>> before.
> >>>>>>
> >>>>>> So apart from my bad communication where I fully agree with you.. do
> >>>>>> you really  think this warrants a -1?
> >>>>>> Do you have any technical concerns?
> >>>>>>
> >>>>>> Christian
> >>>>>>
> >>>>>>
> >>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
> >>>>>> <ma...@googlemail.com>>:
> >>>>>>
> >>>>>>      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
> >>>>>>
> >>>>>>      --
> >>>>>>
> >>>>>>      Apache Member
> >>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
> >>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> >>>>>>      Committer &
> >>>>>>      Project Lead
> >>>>>>      blog <http://notizblog.nierbeck.de/>
> >>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >>>>>>
> >>>>>>      Software Architect / Project Manager / Scrum Master
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> --
> >>>>>> 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
> >>>>>>
> >>>>>> --
> >>>>> 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
> >>>
> >>>
> >>
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>



-- 
http://about.me/milen

Re: bnd files in Decanter Project

["Neil Bartlett (Paremus)" <ne...@paremus.com>]

Hello guys,

I’m not a regular on this list but I was pointed to the discussion, and I think I can clear up a couple of things.

Christian’s information is out of date: there is no longer any need to add an empty bnd.bnd in every project. With the 3.x version of bnd-maven-plugin, the leaf projects don’t need a bnd.bnd file because they inherit bnd settings from the parent project. Leaf projects only need a bnd.bnd if they want to do something special that overrides the parent — in practice this is relatively rare, especially if you are smart about the use of Java annotations like @Version, @ProvideCapability and so on.

Regarding Achim’s assertions about introducing a dependency on Bndtools, this is nonsense. The bnd format is a flat file, it follows the standard Java Properties file syntax. I’m quite confident that IntelliJ, Netbeans or even vi users are able to edit these files.

This isn’t my fight and I really don’t care if Karaf uses bnd-maven-plugin or maven-bundle-plugin. I just thought this information could be useful to somebody.

Kind regards,
Neil


> On 11 Feb 2016, at 22:12, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> I am sorry if I gave the impression to impose this change on others. I just
> did not expect that you would regard it as such a bad thing. You are right
> that I should have done the mailinglist discussion up front. I am sorry
> that I missjudged this situation.
> 
> I was just a bit sad and upset that you took the biggest gun to keep your
> image instead of just pointing out my fault and bring up the issue on the
> list so we can solve it in the correct way that I should have taken in the
> first place. I think the bnd files are not a critical change to the project
> and if the consent or majority is against it I am fully fine to revert it.
> 
> Christian
> 
> 2016-02-11 21:43 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
> 
>> Hi Christian,
>> 
>> I don't think you seem to follow an evil plot, it's just you don't seem to
>> think ahead and take yourself to important.
>> This discussion about bnd.file or not bnd.file should have been done before
>> you provided evidence.
>> A discussion on IRC is as you should be aware of not a valid discussion. So
>> if it didn't happen on the mailinglist, it didn't happen.
>> 
>> At this point I don't get why you now try to turn your "jumping the gun"
>> into me being at fault.
>> 
>> The only change I'm arguing about is the extra bnd.file all other build
>> improvements are regular changes, which I'm not arguing about.
>> Again for me an extra configuration file isn't of any value compared to the
>> configuration contained in the pom.
>> 
>> So this isn't about me insisting you to change everything back, the issue
>> here is that you impose what you think is best on everybody else.
>> 
>> Achim
>> 
>> 
>> 
>> 2016-02-11 20:19 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>> 
>>> Hi Achim,
>>> 
>>> thanks for your detailed description. I can assure you that I do not
>>> follow any evil plot like you seem to think. I will for sure not use
>> gradle
>>> any time soon. I am quite happy with maven and am just trying to make our
>>> project better and the code more efficient. I also was not really sneaky
>> by
>>> creating an issue up front and describing what I want to do. I just did
>> not
>>> to also spawn a discussion on the list to make this more obvious. Please
>> be
>>> assured that the only reason for this was my inherent impatience and good
>>> faith that JB would not have supported my change if he thought it would
>> be
>>> a bad thing for the karaf community. So I was not really aware of doing
>>> something wrong at this time.
>>> 
>>> Please also take into account that your build problem only happened on a
>>> new module you wanted to add and could be fixed by just adding the empty
>>> bnd.bnd file. So I think a -1 while possible was not really necessary. I
>>> think the better option would have been to bring the issue on the list
>> and
>>> try to reach a consensus. I think in my whole apache history I never did
>> a
>>> -1 on a commit.
>>> 
>>> Do you insist on me taking back the commit now or would it be ok to first
>>> try to reach a consensus or if not possible do a vote? I will happily
>> undo
>>> my commit if the outcome is to not do the change. On the other hand if we
>>> agree to do the change it would save me to shuffle the code back and
>> forth.
>>> 
>>> If you insist on this I will undo the changes now. It is probably not
>>> possible to just undo the commit as there are quite a few commits in
>>> between. So it will be quite some manual work for me.
>>> I also hope that if you insist on me taking back the change now you are
>> ok
>>> if I only undo the bnd file part of the commit and leave other changes
>> like
>>> moving some common deps into the parent in place.
>>> 
>>> Christian
>>> 
>>> 
>>> 
>>> On 11.02.2016 17:06, Achim Nierbeck wrote:
>>> 
>>>> Hi there,
>>>> 
>>>> I'll stick to my
>>>> 
>>>> -1
>>>> 
>>>> Now the reasons for this:
>>>> 
>>>> Even though the opposite has been proclaimed on the list, it did break
>> the
>>>> build for me. As without a bnd file the project isn't building
>>>> successfully, even though the information needed has been provided by
>> the
>>>> pom.
>>>> 
>>>> Second the usage of an extra bnd file is error prone, and I don't care
>>>> about removed lines of code, this is just not a justification.
>>>> Another thing why I opposed to extra bnd files. Only on Eclipse when
>> using
>>>> the bnd-tools project you have an extra editor available to use it. And
>>>> this only works for people using both, eclipse and the bnd-tools. All
>>>> others using a different tool chain are losing the benefit to see
>>>> everthing
>>>> in one go.
>>>> So basically people using IntelliJ or Netbeans (both tools to be know to
>>>> work far better with maven, then eclipse) are out of this. And I rather
>>>> don't rely on a proprietary tooling for this.
>>>> 
>>>> So what's next after this? Just sneak the bnd-tools plugins into this
>>>> project for "supposedly" better support with eclipse and bnd-tools?
>>>> I don't think so. Our basis is still Maven and not Gradle, and this is
>>>> because we have a big user-base that feels very comfortable with it.
>>>> Using the declarations in the pom has been working nicely and if nothing
>>>> needs to be done one just needs to add those 4 lines for the usage of
>> the
>>>> maven-bundle-plugin. No extra file needed, everything is in one place
>> and
>>>> is in line with all other Karaf projects.
>>>> Actually this is one of the reasons I removed those bnd files from the
>>>> pax-web project long time ago, because all those project related
>>>> information are in one place now, instead of scattered around the
>> project.
>>>> 
>>>> Third, and this does outweigh everything else. Christian tried to
>> provide
>>>> evidence with this move and now argues this way everything is better for
>>>> us.
>>>> At this point I can't accept this. I don't think this is the way our
>>>> community works and surely this isn't the way we work together on our
>>>> sources. At least
>>>> this has been my understanding of a successful project.
>>>> If I'm wrong on this and everybody can do as he likes, I guess I need
>>>> think
>>>> about the consequences.
>>>> 
>>>> regards, Achim
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>> 
>>>> I see valid arguments here, and I keep my +1.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>> 
>>>>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>>>>> 
>>>>> I also did a jira issue that explains the change.
>>>>>> https://issues.apache.org/jira/browse/KARAF-4300
>>>>>> 
>>>>>> To show the advantage let me compare one of the old configs to the new
>>>>>> one:
>>>>>> http://apaste.info/gC5
>>>>>> 
>>>>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
>> file.
>>>>>> The syntax is basically the same
>>>>>> as in xml just without the brackets. The big advantage is that we can
>>>>>> leave out the boilerplate xml that maven
>>>>>> needs to redefine a plugin.
>>>>>> 
>>>>>> So I think the change to bnd files makes a lot of sense. I also did
>> this
>>>>>> change in Aries a long time ago.
>>>>>> Btw. I also added API baselining in this change which helps us when do
>>>>>> changes on the API.
>>>>>> 
>>>>>> Christian
>>>>>> 
>>>>>> 
>>>>>> On 11.02.2016 14:21, Christian Schneider wrote:
>>>>>> 
>>>>>> As further reference. This is the commit where I did the change:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>>>>> 
>>>>>>> 
>>>>>>> As you can see I added 108 lines and removed 753.
>>>>>>> 
>>>>>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>>>>>> think this is a strong indicator that it is a good idea to do so. Of
>>>>>>> course it might cause problems that I overlooked.
>>>>>>> 
>>>>>>> Christian
>>>>>>> 
>>>>>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>>>>> 
>>>>>>> Hi Achim,
>>>>>>>> 
>>>>>>>> it is difficult to predict what changes warrant a discussion. I
>> agree
>>>>>>>> with you that I should have discussed this on the list. I talked to
>>>>>>>> JB and he was positive so I did not expect any problems. Apparently
>> I
>>>>>>>> was wrong :-(
>>>>>>>> 
>>>>>>>> The usage of bnd files for configuration of the imports and exports
>>>>>>>> is a very concise replacement for the same configs in xml.
>>>>>>>> 
>>>>>>>> The big advantage is that you can omit the maven-bundle-plugin in
>> the
>>>>>>>> pom of each module. So basically you replace about 10-15 lines of
>> xml
>>>>>>>> with 0-5 lines in the bnd file.
>>>>>>>> 
>>>>>>>> This does not break any functionality for users. For developers it
>>>>>>>> just requires to put an empty bnd.bnd file into each module if it
>>>>>>>> does not need special configs. Unfortunately it is not possible to
>>>>>>>> define that it uses a bnd file if it is there  and is also happy if
>>>>>>>> no such file is there. I plan to suggest this to the felix project
>> as
>>>>>>>> it would make this even easier to use.
>>>>>>>> 
>>>>>>>> In what way do you see this as a breaking change? I made sure that
>>>>>>>> all code still works and that all tests still pass. I also did
>> manual
>>>>>>>> tests of all the modules.
>>>>>>>> 
>>>>>>>> So the only thing you need to do for a new module is to add this
>>>>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>>>>>> bnd file to configure your OSGi configs you can use the xml like
>>>>>>>> before.
>>>>>>>> 
>>>>>>>> So apart from my bad communication where I fully agree with you.. do
>>>>>>>> you really  think this warrants a -1?
>>>>>>>> Do you have any technical concerns?
>>>>>>>> 
>>>>>>>> Christian
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>>>>>> <ma...@googlemail.com>>:
>>>>>>>> 
>>>>>>>>     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
>>>>>>>> 
>>>>>>>>     --
>>>>>>>> 
>>>>>>>>     Apache Member
>>>>>>>>     Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>>>     OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>>>     Committer &
>>>>>>>>     Project Lead
>>>>>>>>     blog <http://notizblog.nierbeck.de/>
>>>>>>>>     Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>>> 
>>>>>>>>     Software Architect / Project Manager / Scrum Master
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> --
>>>>>>>> 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
>>>>>>>> 
>>>>>>>> --
>>>>>>> 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
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Open Source Architect
>>> http://www.talend.com
>>> 
>>> 
>> 
>> 
>> --
>> 
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>> 
>> Software Architect / Project Manager / Scrum Master
>> 
> 
> 
> 
> -- 
> -- 
> 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>

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

I am sorry if I gave the impression to impose this change on others. I just
did not expect that you would regard it as such a bad thing. You are right
that I should have done the mailinglist discussion up front. I am sorry
that I missjudged this situation.

I was just a bit sad and upset that you took the biggest gun to keep your
image instead of just pointing out my fault and bring up the issue on the
list so we can solve it in the correct way that I should have taken in the
first place. I think the bnd files are not a critical change to the project
and if the consent or majority is against it I am fully fine to revert it.

Christian

2016-02-11 21:43 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:

> Hi Christian,
>
> I don't think you seem to follow an evil plot, it's just you don't seem to
> think ahead and take yourself to important.
> This discussion about bnd.file or not bnd.file should have been done before
> you provided evidence.
> A discussion on IRC is as you should be aware of not a valid discussion. So
> if it didn't happen on the mailinglist, it didn't happen.
>
> At this point I don't get why you now try to turn your "jumping the gun"
> into me being at fault.
>
> The only change I'm arguing about is the extra bnd.file all other build
> improvements are regular changes, which I'm not arguing about.
> Again for me an extra configuration file isn't of any value compared to the
> configuration contained in the pom.
>
> So this isn't about me insisting you to change everything back, the issue
> here is that you impose what you think is best on everybody else.
>
> Achim
>
>
>
> 2016-02-11 20:19 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
> > Hi Achim,
> >
> > thanks for your detailed description. I can assure you that I do not
> > follow any evil plot like you seem to think. I will for sure not use
> gradle
> > any time soon. I am quite happy with maven and am just trying to make our
> > project better and the code more efficient. I also was not really sneaky
> by
> > creating an issue up front and describing what I want to do. I just did
> not
> > to also spawn a discussion on the list to make this more obvious. Please
> be
> > assured that the only reason for this was my inherent impatience and good
> > faith that JB would not have supported my change if he thought it would
> be
> > a bad thing for the karaf community. So I was not really aware of doing
> > something wrong at this time.
> >
> > Please also take into account that your build problem only happened on a
> > new module you wanted to add and could be fixed by just adding the empty
> > bnd.bnd file. So I think a -1 while possible was not really necessary. I
> > think the better option would have been to bring the issue on the list
> and
> > try to reach a consensus. I think in my whole apache history I never did
> a
> > -1 on a commit.
> >
> > Do you insist on me taking back the commit now or would it be ok to first
> > try to reach a consensus or if not possible do a vote? I will happily
> undo
> > my commit if the outcome is to not do the change. On the other hand if we
> > agree to do the change it would save me to shuffle the code back and
> forth.
> >
> > If you insist on this I will undo the changes now. It is probably not
> > possible to just undo the commit as there are quite a few commits in
> > between. So it will be quite some manual work for me.
> > I also hope that if you insist on me taking back the change now you are
> ok
> > if I only undo the bnd file part of the commit and leave other changes
> like
> > moving some common deps into the parent in place.
> >
> > Christian
> >
> >
> >
> > On 11.02.2016 17:06, Achim Nierbeck wrote:
> >
> >> Hi there,
> >>
> >> I'll stick to my
> >>
> >> -1
> >>
> >> Now the reasons for this:
> >>
> >> Even though the opposite has been proclaimed on the list, it did break
> the
> >> build for me. As without a bnd file the project isn't building
> >> successfully, even though the information needed has been provided by
> the
> >> pom.
> >>
> >> Second the usage of an extra bnd file is error prone, and I don't care
> >> about removed lines of code, this is just not a justification.
> >> Another thing why I opposed to extra bnd files. Only on Eclipse when
> using
> >> the bnd-tools project you have an extra editor available to use it. And
> >> this only works for people using both, eclipse and the bnd-tools. All
> >> others using a different tool chain are losing the benefit to see
> >> everthing
> >> in one go.
> >> So basically people using IntelliJ or Netbeans (both tools to be know to
> >> work far better with maven, then eclipse) are out of this. And I rather
> >> don't rely on a proprietary tooling for this.
> >>
> >> So what's next after this? Just sneak the bnd-tools plugins into this
> >> project for "supposedly" better support with eclipse and bnd-tools?
> >> I don't think so. Our basis is still Maven and not Gradle, and this is
> >> because we have a big user-base that feels very comfortable with it.
> >> Using the declarations in the pom has been working nicely and if nothing
> >> needs to be done one just needs to add those 4 lines for the usage of
> the
> >> maven-bundle-plugin. No extra file needed, everything is in one place
> and
> >> is in line with all other Karaf projects.
> >> Actually this is one of the reasons I removed those bnd files from the
> >> pax-web project long time ago, because all those project related
> >> information are in one place now, instead of scattered around the
> project.
> >>
> >> Third, and this does outweigh everything else. Christian tried to
> provide
> >> evidence with this move and now argues this way everything is better for
> >> us.
> >> At this point I can't accept this. I don't think this is the way our
> >> community works and surely this isn't the way we work together on our
> >> sources. At least
> >> this has been my understanding of a successful project.
> >> If I'm wrong on this and everybody can do as he likes, I guess I need
> >> think
> >> about the consequences.
> >>
> >> regards, Achim
> >>
> >>
> >>
> >>
> >> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >>
> >> I see valid arguments here, and I keep my +1.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
> >>>
> >>> I also did a jira issue that explains the change.
> >>>> https://issues.apache.org/jira/browse/KARAF-4300
> >>>>
> >>>> To show the advantage let me compare one of the old configs to the new
> >>>> one:
> >>>> http://apaste.info/gC5
> >>>>
> >>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd
> file.
> >>>> The syntax is basically the same
> >>>> as in xml just without the brackets. The big advantage is that we can
> >>>> leave out the boilerplate xml that maven
> >>>> needs to redefine a plugin.
> >>>>
> >>>> So I think the change to bnd files makes a lot of sense. I also did
> this
> >>>> change in Aries a long time ago.
> >>>> Btw. I also added API baselining in this change which helps us when do
> >>>> changes on the API.
> >>>>
> >>>> Christian
> >>>>
> >>>>
> >>>> On 11.02.2016 14:21, Christian Schneider wrote:
> >>>>
> >>>> As further reference. This is the commit where I did the change:
> >>>>>
> >>>>>
> >>>>>
> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
> >>>>>
> >>>>>
> >>>>> As you can see I added 108 lines and removed 753.
> >>>>>
> >>>>> That means the usage of bnd files saves us about 640 lines of xml. I
> >>>>> think this is a strong indicator that it is a good idea to do so. Of
> >>>>> course it might cause problems that I overlooked.
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> On 11.02.2016 13:57, Christian Schneider wrote:
> >>>>>
> >>>>> Hi Achim,
> >>>>>>
> >>>>>> it is difficult to predict what changes warrant a discussion. I
> agree
> >>>>>> with you that I should have discussed this on the list. I talked to
> >>>>>> JB and he was positive so I did not expect any problems. Apparently
> I
> >>>>>> was wrong :-(
> >>>>>>
> >>>>>> The usage of bnd files for configuration of the imports and exports
> >>>>>> is a very concise replacement for the same configs in xml.
> >>>>>>
> >>>>>> The big advantage is that you can omit the maven-bundle-plugin in
> the
> >>>>>> pom of each module. So basically you replace about 10-15 lines of
> xml
> >>>>>> with 0-5 lines in the bnd file.
> >>>>>>
> >>>>>> This does not break any functionality for users. For developers it
> >>>>>> just requires to put an empty bnd.bnd file into each module if it
> >>>>>> does not need special configs. Unfortunately it is not possible to
> >>>>>> define that it uses a bnd file if it is there  and is also happy if
> >>>>>> no such file is there. I plan to suggest this to the felix project
> as
> >>>>>> it would make this even easier to use.
> >>>>>>
> >>>>>> In what way do you see this as a breaking change? I made sure that
> >>>>>> all code still works and that all tests still pass. I also did
> manual
> >>>>>> tests of all the modules.
> >>>>>>
> >>>>>> So the only thing you need to do for a new module is to add this
> >>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
> >>>>>> bnd file to configure your OSGi configs you can use the xml like
> >>>>>> before.
> >>>>>>
> >>>>>> So apart from my bad communication where I fully agree with you.. do
> >>>>>> you really  think this warrants a -1?
> >>>>>> Do you have any technical concerns?
> >>>>>>
> >>>>>> Christian
> >>>>>>
> >>>>>>
> >>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
> >>>>>> <ma...@googlemail.com>>:
> >>>>>>
> >>>>>>      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
> >>>>>>
> >>>>>>      --
> >>>>>>
> >>>>>>      Apache Member
> >>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
> >>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> >>>>>>      Committer &
> >>>>>>      Project Lead
> >>>>>>      blog <http://notizblog.nierbeck.de/>
> >>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >>>>>>
> >>>>>>      Software Architect / Project Manager / Scrum Master
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> --
> >>>>>> 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
> >>>>>>
> >>>>>> --
> >>>>> 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
> >>>
> >>>
> >>
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>



-- 
-- 
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>

Re: bnd files in Decanter Project

[Achim Nierbeck <bc...@googlemail.com>]

Hi Christian,

I don't think you seem to follow an evil plot, it's just you don't seem to
think ahead and take yourself to important.
This discussion about bnd.file or not bnd.file should have been done before
you provided evidence.
A discussion on IRC is as you should be aware of not a valid discussion. So
if it didn't happen on the mailinglist, it didn't happen.

At this point I don't get why you now try to turn your "jumping the gun"
into me being at fault.

The only change I'm arguing about is the extra bnd.file all other build
improvements are regular changes, which I'm not arguing about.
Again for me an extra configuration file isn't of any value compared to the
configuration contained in the pom.

So this isn't about me insisting you to change everything back, the issue
here is that you impose what you think is best on everybody else.

Achim



2016-02-11 20:19 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:

> Hi Achim,
>
> thanks for your detailed description. I can assure you that I do not
> follow any evil plot like you seem to think. I will for sure not use gradle
> any time soon. I am quite happy with maven and am just trying to make our
> project better and the code more efficient. I also was not really sneaky by
> creating an issue up front and describing what I want to do. I just did not
> to also spawn a discussion on the list to make this more obvious. Please be
> assured that the only reason for this was my inherent impatience and good
> faith that JB would not have supported my change if he thought it would be
> a bad thing for the karaf community. So I was not really aware of doing
> something wrong at this time.
>
> Please also take into account that your build problem only happened on a
> new module you wanted to add and could be fixed by just adding the empty
> bnd.bnd file. So I think a -1 while possible was not really necessary. I
> think the better option would have been to bring the issue on the list and
> try to reach a consensus. I think in my whole apache history I never did a
> -1 on a commit.
>
> Do you insist on me taking back the commit now or would it be ok to first
> try to reach a consensus or if not possible do a vote? I will happily undo
> my commit if the outcome is to not do the change. On the other hand if we
> agree to do the change it would save me to shuffle the code back and  forth.
>
> If you insist on this I will undo the changes now. It is probably not
> possible to just undo the commit as there are quite a few commits in
> between. So it will be quite some manual work for me.
> I also hope that if you insist on me taking back the change now you are ok
> if I only undo the bnd file part of the commit and leave other changes like
> moving some common deps into the parent in place.
>
> Christian
>
>
>
> On 11.02.2016 17:06, Achim Nierbeck wrote:
>
>> Hi there,
>>
>> I'll stick to my
>>
>> -1
>>
>> Now the reasons for this:
>>
>> Even though the opposite has been proclaimed on the list, it did break the
>> build for me. As without a bnd file the project isn't building
>> successfully, even though the information needed has been provided by the
>> pom.
>>
>> Second the usage of an extra bnd file is error prone, and I don't care
>> about removed lines of code, this is just not a justification.
>> Another thing why I opposed to extra bnd files. Only on Eclipse when using
>> the bnd-tools project you have an extra editor available to use it. And
>> this only works for people using both, eclipse and the bnd-tools. All
>> others using a different tool chain are losing the benefit to see
>> everthing
>> in one go.
>> So basically people using IntelliJ or Netbeans (both tools to be know to
>> work far better with maven, then eclipse) are out of this. And I rather
>> don't rely on a proprietary tooling for this.
>>
>> So what's next after this? Just sneak the bnd-tools plugins into this
>> project for "supposedly" better support with eclipse and bnd-tools?
>> I don't think so. Our basis is still Maven and not Gradle, and this is
>> because we have a big user-base that feels very comfortable with it.
>> Using the declarations in the pom has been working nicely and if nothing
>> needs to be done one just needs to add those 4 lines for the usage of the
>> maven-bundle-plugin. No extra file needed, everything is in one place and
>> is in line with all other Karaf projects.
>> Actually this is one of the reasons I removed those bnd files from the
>> pax-web project long time ago, because all those project related
>> information are in one place now, instead of scattered around the project.
>>
>> Third, and this does outweigh everything else. Christian tried to provide
>> evidence with this move and now argues this way everything is better for
>> us.
>> At this point I can't accept this. I don't think this is the way our
>> community works and surely this isn't the way we work together on our
>> sources. At least
>> this has been my understanding of a successful project.
>> If I'm wrong on this and everybody can do as he likes, I guess I need
>> think
>> about the consequences.
>>
>> regards, Achim
>>
>>
>>
>>
>> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>
>> I see valid arguments here, and I keep my +1.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>>>
>>> I also did a jira issue that explains the change.
>>>> https://issues.apache.org/jira/browse/KARAF-4300
>>>>
>>>> To show the advantage let me compare one of the old configs to the new
>>>> one:
>>>> http://apaste.info/gC5
>>>>
>>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd file.
>>>> The syntax is basically the same
>>>> as in xml just without the brackets. The big advantage is that we can
>>>> leave out the boilerplate xml that maven
>>>> needs to redefine a plugin.
>>>>
>>>> So I think the change to bnd files makes a lot of sense. I also did this
>>>> change in Aries a long time ago.
>>>> Btw. I also added API baselining in this change which helps us when do
>>>> changes on the API.
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 11.02.2016 14:21, Christian Schneider wrote:
>>>>
>>>> As further reference. This is the commit where I did the change:
>>>>>
>>>>>
>>>>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>>>
>>>>>
>>>>> As you can see I added 108 lines and removed 753.
>>>>>
>>>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>>>> think this is a strong indicator that it is a good idea to do so. Of
>>>>> course it might cause problems that I overlooked.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>>>
>>>>> Hi Achim,
>>>>>>
>>>>>> it is difficult to predict what changes warrant a discussion. I agree
>>>>>> with you that I should have discussed this on the list. I talked to
>>>>>> JB and he was positive so I did not expect any problems. Apparently I
>>>>>> was wrong :-(
>>>>>>
>>>>>> The usage of bnd files for configuration of the imports and exports
>>>>>> is a very concise replacement for the same configs in xml.
>>>>>>
>>>>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>>>>> pom of each module. So basically you replace about 10-15 lines of xml
>>>>>> with 0-5 lines in the bnd file.
>>>>>>
>>>>>> This does not break any functionality for users. For developers it
>>>>>> just requires to put an empty bnd.bnd file into each module if it
>>>>>> does not need special configs. Unfortunately it is not possible to
>>>>>> define that it uses a bnd file if it is there  and is also happy if
>>>>>> no such file is there. I plan to suggest this to the felix project as
>>>>>> it would make this even easier to use.
>>>>>>
>>>>>> In what way do you see this as a breaking change? I made sure that
>>>>>> all code still works and that all tests still pass. I also did manual
>>>>>> tests of all the modules.
>>>>>>
>>>>>> So the only thing you need to do for a new module is to add this
>>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>>>> bnd file to configure your OSGi configs you can use the xml like
>>>>>> before.
>>>>>>
>>>>>> So apart from my bad communication where I fully agree with you.. do
>>>>>> you really  think this warrants a -1?
>>>>>> Do you have any technical concerns?
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>>>> <ma...@googlemail.com>>:
>>>>>>
>>>>>>      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
>>>>>>
>>>>>>      --
>>>>>>
>>>>>>      Apache Member
>>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>>      Committer &
>>>>>>      Project Lead
>>>>>>      blog <http://notizblog.nierbeck.de/>
>>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>>
>>>>>>      Software Architect / Project Manager / Scrum Master
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>> --
>>>>> 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
>>>
>>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

Hi Achim,

thanks for your detailed description. I can assure you that I do not 
follow any evil plot like you seem to think. I will for sure not use 
gradle any time soon. I am quite happy with maven and am just trying to 
make our project better and the code more efficient. I also was not 
really sneaky by creating an issue up front and describing what I want 
to do. I just did not to also spawn a discussion on the list to make 
this more obvious. Please be assured that the only reason for this was 
my inherent impatience and good faith that JB would not have supported 
my change if he thought it would be a bad thing for the karaf community. 
So I was not really aware of doing something wrong at this time.

Please also take into account that your build problem only happened on a 
new module you wanted to add and could be fixed by just adding the empty 
bnd.bnd file. So I think a -1 while possible was not really necessary. I 
think the better option would have been to bring the issue on the list 
and try to reach a consensus. I think in my whole apache history I never 
did a -1 on a commit.

Do you insist on me taking back the commit now or would it be ok to 
first try to reach a consensus or if not possible do a vote? I will 
happily undo my commit if the outcome is to not do the change. On the 
other hand if we agree to do the change it would save me to shuffle the 
code back and  forth.

If you insist on this I will undo the changes now. It is probably not 
possible to just undo the commit as there are quite a few commits in 
between. So it will be quite some manual work for me.
I also hope that if you insist on me taking back the change now you are 
ok if I only undo the bnd file part of the commit and leave other 
changes like moving some common deps into the parent in place.

Christian


On 11.02.2016 17:06, Achim Nierbeck wrote:
> Hi there,
>
> I'll stick to my
>
> -1
>
> Now the reasons for this:
>
> Even though the opposite has been proclaimed on the list, it did break the
> build for me. As without a bnd file the project isn't building
> successfully, even though the information needed has been provided by the
> pom.
>
> Second the usage of an extra bnd file is error prone, and I don't care
> about removed lines of code, this is just not a justification.
> Another thing why I opposed to extra bnd files. Only on Eclipse when using
> the bnd-tools project you have an extra editor available to use it. And
> this only works for people using both, eclipse and the bnd-tools. All
> others using a different tool chain are losing the benefit to see everthing
> in one go.
> So basically people using IntelliJ or Netbeans (both tools to be know to
> work far better with maven, then eclipse) are out of this. And I rather
> don't rely on a proprietary tooling for this.
>
> So what's next after this? Just sneak the bnd-tools plugins into this
> project for "supposedly" better support with eclipse and bnd-tools?
> I don't think so. Our basis is still Maven and not Gradle, and this is
> because we have a big user-base that feels very comfortable with it.
> Using the declarations in the pom has been working nicely and if nothing
> needs to be done one just needs to add those 4 lines for the usage of the
> maven-bundle-plugin. No extra file needed, everything is in one place and
> is in line with all other Karaf projects.
> Actually this is one of the reasons I removed those bnd files from the
> pax-web project long time ago, because all those project related
> information are in one place now, instead of scattered around the project.
>
> Third, and this does outweigh everything else. Christian tried to provide
> evidence with this move and now argues this way everything is better for
> us.
> At this point I can't accept this. I don't think this is the way our
> community works and surely this isn't the way we work together on our
> sources. At least
> this has been my understanding of a successful project.
> If I'm wrong on this and everybody can do as he likes, I guess I need think
> about the consequences.
>
> regards, Achim
>
>
>
>
> 2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
>> I see valid arguments here, and I keep my +1.
>>
>> Regards
>> JB
>>
>>
>> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>>
>>> I also did a jira issue that explains the change.
>>> https://issues.apache.org/jira/browse/KARAF-4300
>>>
>>> To show the advantage let me compare one of the old configs to the new
>>> one:
>>> http://apaste.info/gC5
>>>
>>> This shows that 18 lines of xml are replaced by 2 lines in the bnd file.
>>> The syntax is basically the same
>>> as in xml just without the brackets. The big advantage is that we can
>>> leave out the boilerplate xml that maven
>>> needs to redefine a plugin.
>>>
>>> So I think the change to bnd files makes a lot of sense. I also did this
>>> change in Aries a long time ago.
>>> Btw. I also added API baselining in this change which helps us when do
>>> changes on the API.
>>>
>>> Christian
>>>
>>>
>>> On 11.02.2016 14:21, Christian Schneider wrote:
>>>
>>>> As further reference. This is the commit where I did the change:
>>>>
>>>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>>
>>>>
>>>> As you can see I added 108 lines and removed 753.
>>>>
>>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>>> think this is a strong indicator that it is a good idea to do so. Of
>>>> course it might cause problems that I overlooked.
>>>>
>>>> Christian
>>>>
>>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>>
>>>>> Hi Achim,
>>>>>
>>>>> it is difficult to predict what changes warrant a discussion. I agree
>>>>> with you that I should have discussed this on the list. I talked to
>>>>> JB and he was positive so I did not expect any problems. Apparently I
>>>>> was wrong :-(
>>>>>
>>>>> The usage of bnd files for configuration of the imports and exports
>>>>> is a very concise replacement for the same configs in xml.
>>>>>
>>>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>>>> pom of each module. So basically you replace about 10-15 lines of xml
>>>>> with 0-5 lines in the bnd file.
>>>>>
>>>>> This does not break any functionality for users. For developers it
>>>>> just requires to put an empty bnd.bnd file into each module if it
>>>>> does not need special configs. Unfortunately it is not possible to
>>>>> define that it uses a bnd file if it is there  and is also happy if
>>>>> no such file is there. I plan to suggest this to the felix project as
>>>>> it would make this even easier to use.
>>>>>
>>>>> In what way do you see this as a breaking change? I made sure that
>>>>> all code still works and that all tests still pass. I also did manual
>>>>> tests of all the modules.
>>>>>
>>>>> So the only thing you need to do for a new module is to add this
>>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>>> bnd file to configure your OSGi configs you can use the xml like before.
>>>>>
>>>>> So apart from my bad communication where I fully agree with you.. do
>>>>> you really  think this warrants a -1?
>>>>> Do you have any technical concerns?
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>>> <ma...@googlemail.com>>:
>>>>>
>>>>>      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
>>>>>
>>>>>      --
>>>>>
>>>>>      Apache Member
>>>>>      Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>>      OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>>      Committer &
>>>>>      Project Lead
>>>>>      blog <http://notizblog.nierbeck.de/>
>>>>>      Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>>
>>>>>      Software Architect / Project Manager / Scrum Master
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> 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
>>>>>
>>>> --
>>>> 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
>>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Achim Nierbeck <bc...@googlemail.com>]

Hi there,

I'll stick to my

-1

Now the reasons for this:

Even though the opposite has been proclaimed on the list, it did break the
build for me. As without a bnd file the project isn't building
successfully, even though the information needed has been provided by the
pom.

Second the usage of an extra bnd file is error prone, and I don't care
about removed lines of code, this is just not a justification.
Another thing why I opposed to extra bnd files. Only on Eclipse when using
the bnd-tools project you have an extra editor available to use it. And
this only works for people using both, eclipse and the bnd-tools. All
others using a different tool chain are losing the benefit to see everthing
in one go.
So basically people using IntelliJ or Netbeans (both tools to be know to
work far better with maven, then eclipse) are out of this. And I rather
don't rely on a proprietary tooling for this.

So what's next after this? Just sneak the bnd-tools plugins into this
project for "supposedly" better support with eclipse and bnd-tools?
I don't think so. Our basis is still Maven and not Gradle, and this is
because we have a big user-base that feels very comfortable with it.
Using the declarations in the pom has been working nicely and if nothing
needs to be done one just needs to add those 4 lines for the usage of the
maven-bundle-plugin. No extra file needed, everything is in one place and
is in line with all other Karaf projects.
Actually this is one of the reasons I removed those bnd files from the
pax-web project long time ago, because all those project related
information are in one place now, instead of scattered around the project.

Third, and this does outweigh everything else. Christian tried to provide
evidence with this move and now argues this way everything is better for
us.
At this point I can't accept this. I don't think this is the way our
community works and surely this isn't the way we work together on our
sources. At least
this has been my understanding of a successful project.
If I'm wrong on this and everybody can do as he likes, I guess I need think
about the consequences.

regards, Achim




2016-02-11 15:12 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> I see valid arguments here, and I keep my +1.
>
> Regards
> JB
>
>
> On 02/11/2016 02:40 PM, Christian Schneider wrote:
>
>> I also did a jira issue that explains the change.
>> https://issues.apache.org/jira/browse/KARAF-4300
>>
>> To show the advantage let me compare one of the old configs to the new
>> one:
>> http://apaste.info/gC5
>>
>> This shows that 18 lines of xml are replaced by 2 lines in the bnd file.
>> The syntax is basically the same
>> as in xml just without the brackets. The big advantage is that we can
>> leave out the boilerplate xml that maven
>> needs to redefine a plugin.
>>
>> So I think the change to bnd files makes a lot of sense. I also did this
>> change in Aries a long time ago.
>> Btw. I also added API baselining in this change which helps us when do
>> changes on the API.
>>
>> Christian
>>
>>
>> On 11.02.2016 14:21, Christian Schneider wrote:
>>
>>> As further reference. This is the commit where I did the change:
>>>
>>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>>
>>>
>>> As you can see I added 108 lines and removed 753.
>>>
>>> That means the usage of bnd files saves us about 640 lines of xml. I
>>> think this is a strong indicator that it is a good idea to do so. Of
>>> course it might cause problems that I overlooked.
>>>
>>> Christian
>>>
>>> On 11.02.2016 13:57, Christian Schneider wrote:
>>>
>>>> Hi Achim,
>>>>
>>>> it is difficult to predict what changes warrant a discussion. I agree
>>>> with you that I should have discussed this on the list. I talked to
>>>> JB and he was positive so I did not expect any problems. Apparently I
>>>> was wrong :-(
>>>>
>>>> The usage of bnd files for configuration of the imports and exports
>>>> is a very concise replacement for the same configs in xml.
>>>>
>>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>>> pom of each module. So basically you replace about 10-15 lines of xml
>>>> with 0-5 lines in the bnd file.
>>>>
>>>> This does not break any functionality for users. For developers it
>>>> just requires to put an empty bnd.bnd file into each module if it
>>>> does not need special configs. Unfortunately it is not possible to
>>>> define that it uses a bnd file if it is there  and is also happy if
>>>> no such file is there. I plan to suggest this to the felix project as
>>>> it would make this even easier to use.
>>>>
>>>> In what way do you see this as a breaking change? I made sure that
>>>> all code still works and that all tests still pass. I also did manual
>>>> tests of all the modules.
>>>>
>>>> So the only thing you need to do for a new module is to add this
>>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>>> bnd file to configure your OSGi configs you can use the xml like before.
>>>>
>>>> So apart from my bad communication where I fully agree with you.. do
>>>> you really  think this warrants a -1?
>>>> Do you have any technical concerns?
>>>>
>>>> Christian
>>>>
>>>>
>>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>>> <ma...@googlemail.com>>:
>>>>
>>>>     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
>>>>
>>>>     --
>>>>
>>>>     Apache Member
>>>>     Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>>     OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>>     Committer &
>>>>     Project Lead
>>>>     blog <http://notizblog.nierbeck.de/>
>>>>     Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>>     Software Architect / Project Manager / Scrum Master
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> 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
>>>> >
>>>>
>>>>
>>>
>>> --
>>> 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
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

I see valid arguments here, and I keep my +1.

Regards
JB

On 02/11/2016 02:40 PM, Christian Schneider wrote:
> I also did a jira issue that explains the change.
> https://issues.apache.org/jira/browse/KARAF-4300
>
> To show the advantage let me compare one of the old configs to the new one:
> http://apaste.info/gC5
>
> This shows that 18 lines of xml are replaced by 2 lines in the bnd file.
> The syntax is basically the same
> as in xml just without the brackets. The big advantage is that we can
> leave out the boilerplate xml that maven
> needs to redefine a plugin.
>
> So I think the change to bnd files makes a lot of sense. I also did this
> change in Aries a long time ago.
> Btw. I also added API baselining in this change which helps us when do
> changes on the API.
>
> Christian
>
>
> On 11.02.2016 14:21, Christian Schneider wrote:
>> As further reference. This is the commit where I did the change:
>> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>>
>>
>> As you can see I added 108 lines and removed 753.
>>
>> That means the usage of bnd files saves us about 640 lines of xml. I
>> think this is a strong indicator that it is a good idea to do so. Of
>> course it might cause problems that I overlooked.
>>
>> Christian
>>
>> On 11.02.2016 13:57, Christian Schneider wrote:
>>> Hi Achim,
>>>
>>> it is difficult to predict what changes warrant a discussion. I agree
>>> with you that I should have discussed this on the list. I talked to
>>> JB and he was positive so I did not expect any problems. Apparently I
>>> was wrong :-(
>>>
>>> The usage of bnd files for configuration of the imports and exports
>>> is a very concise replacement for the same configs in xml.
>>>
>>> The big advantage is that you can omit the maven-bundle-plugin in the
>>> pom of each module. So basically you replace about 10-15 lines of xml
>>> with 0-5 lines in the bnd file.
>>>
>>> This does not break any functionality for users. For developers it
>>> just requires to put an empty bnd.bnd file into each module if it
>>> does not need special configs. Unfortunately it is not possible to
>>> define that it uses a bnd file if it is there  and is also happy if
>>> no such file is there. I plan to suggest this to the felix project as
>>> it would make this even easier to use.
>>>
>>> In what way do you see this as a breaking change? I made sure that
>>> all code still works and that all tests still pass. I also did manual
>>> tests of all the modules.
>>>
>>> So the only thing you need to do for a new module is to add this
>>> empty bnd.bnd file and you are fine. If you do not want to use the
>>> bnd file to configure your OSGi configs you can use the xml like before.
>>>
>>> So apart from my bad communication where I fully agree with you.. do
>>> you really  think this warrants a -1?
>>> Do you have any technical concerns?
>>>
>>> Christian
>>>
>>>
>>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com
>>> <ma...@googlemail.com>>:
>>>
>>>     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
>>>
>>>     --
>>>
>>>     Apache Member
>>>     Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>     OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>     Committer &
>>>     Project Lead
>>>     blog <http://notizblog.nierbeck.de/>
>>>     Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>>     Software Architect / Project Manager / Scrum Master
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> 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>
>>>
>>
>>
>> --
>> 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

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

I also did a jira issue that explains the change.
https://issues.apache.org/jira/browse/KARAF-4300

To show the advantage let me compare one of the old configs to the new one:
http://apaste.info/gC5

This shows that 18 lines of xml are replaced by 2 lines in the bnd file. 
The syntax is basically the same
as in xml just without the brackets. The big advantage is that we can 
leave out the boilerplate xml that maven
needs to redefine a plugin.

So I think the change to bnd files makes a lot of sense. I also did this 
change in Aries a long time ago.
Btw. I also added API baselining in this change which helps us when do 
changes on the API.

Christian


On 11.02.2016 14:21, Christian Schneider wrote:
> As further reference. This is the commit where I did the change:
> https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35
>
> As you can see I added 108 lines and removed 753.
>
> That means the usage of bnd files saves us about 640 lines of xml. I 
> think this is a strong indicator that it is a good idea to do so. Of 
> course it might cause problems that I overlooked.
>
> Christian
>
> On 11.02.2016 13:57, Christian Schneider wrote:
>> Hi Achim,
>>
>> it is difficult to predict what changes warrant a discussion. I agree 
>> with you that I should have discussed this on the list. I talked to 
>> JB and he was positive so I did not expect any problems. Apparently I 
>> was wrong :-(
>>
>> The usage of bnd files for configuration of the imports and exports 
>> is a very concise replacement for the same configs in xml.
>>
>> The big advantage is that you can omit the maven-bundle-plugin in the 
>> pom of each module. So basically you replace about 10-15 lines of xml 
>> with 0-5 lines in the bnd file.
>>
>> This does not break any functionality for users. For developers it 
>> just requires to put an empty bnd.bnd file into each module if it 
>> does not need special configs. Unfortunately it is not possible to 
>> define that it uses a bnd file if it is there  and is also happy if 
>> no such file is there. I plan to suggest this to the felix project as 
>> it would make this even easier to use.
>>
>> In what way do you see this as a breaking change? I made sure that 
>> all code still works and that all tests still pass. I also did manual 
>> tests of all the modules.
>>
>> So the only thing you need to do for a new module is to add this 
>> empty bnd.bnd file and you are fine. If you do not want to use the 
>> bnd file to configure your OSGi configs you can use the xml like before.
>>
>> So apart from my bad communication where I fully agree with you.. do 
>> you really  think this warrants a -1?
>> Do you have any technical concerns?
>>
>> Christian
>>
>>
>> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com 
>> <ma...@googlemail.com>>:
>>
>>     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
>>
>>     --
>>
>>     Apache Member
>>     Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>     OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>     Committer &
>>     Project Lead
>>     blog <http://notizblog.nierbeck.de/>
>>     Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>>     Software Architect / Project Manager / Scrum Master
>>
>>
>>
>>
>> -- 
>> -- 
>> 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>
>
>
> -- 
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

As further reference. This is the commit where I did the change:
https://github.com/apache/karaf-decanter/commit/dabeeecd41f46a0c5344580f65c2ea6877fd6d35

As you can see I added 108 lines and removed 753.

That means the usage of bnd files saves us about 640 lines of xml. I 
think this is a strong indicator that it is a good idea to do so. Of 
course it might cause problems that I overlooked.

Christian

On 11.02.2016 13:57, Christian Schneider wrote:
> Hi Achim,
>
> it is difficult to predict what changes warrant a discussion. I agree 
> with you that I should have discussed this on the list. I talked to JB 
> and he was positive so I did not expect any problems. Apparently I was 
> wrong :-(
>
> The usage of bnd files for configuration of the imports and exports is 
> a very concise replacement for the same configs in xml.
>
> The big advantage is that you can omit the maven-bundle-plugin in the 
> pom of each module. So basically you replace about 10-15 lines of xml 
> with 0-5 lines in the bnd file.
>
> This does not break any functionality for users. For developers it 
> just requires to put an empty bnd.bnd file into each module if it does 
> not need special configs. Unfortunately it is not possible to define 
> that it uses a bnd file if it is there  and is also happy if no such 
> file is there. I plan to suggest this to the felix project as it would 
> make this even easier to use.
>
> In what way do you see this as a breaking change? I made sure that all 
> code still works and that all tests still pass. I also did manual 
> tests of all the modules.
>
> So the only thing you need to do for a new module is to add this empty 
> bnd.bnd file and you are fine. If you do not want to use the bnd file 
> to configure your OSGi configs you can use the xml like before.
>
> So apart from my bad communication where I fully agree with you.. do 
> you really  think this warrants a -1?
> Do you have any technical concerns?
>
> Christian
>
>
> 2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com 
> <ma...@googlemail.com>>:
>
>     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
>
>     --
>
>     Apache Member
>     Apache Karaf <http://karaf.apache.org/> Committer & PMC
>     OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>     Committer &
>     Project Lead
>     blog <http://notizblog.nierbeck.de/>
>     Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
>     Software Architect / Project Manager / Scrum Master
>
>
>
>
> -- 
> -- 
> 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>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

Hi Achim,

it is difficult to predict what changes warrant a discussion. I agree with
you that I should have discussed this on the list. I talked to JB and he
was positive so I did not expect any problems. Apparently I was wrong :-(

The usage of bnd files for configuration of the imports and exports is a
very concise replacement for the same configs in xml.

The big advantage is that you can omit the maven-bundle-plugin in the pom
of each module. So basically you replace about 10-15 lines of xml with 0-5
lines in the bnd file.

This does not break any functionality for users. For developers it just
requires to put an empty bnd.bnd file into each module if it does not need
special configs. Unfortunately it is not possible to define that it uses a
bnd file if it is there  and is also happy if no such file is there. I plan
to suggest this to the felix project as it would make this even easier to
use.

In what way do you see this as a breaking change? I made sure that all code
still works and that all tests still pass. I also did manual tests of all
the modules.

So the only thing you need to do for a new module is to add this empty
bnd.bnd file and you are fine. If you do not want to use the bnd file to
configure your OSGi configs you can use the xml like before.

So apart from my bad communication where I fully agree with you.. do you
really  think this warrants a -1?
Do you have any technical concerns?

Christian


2016-02-11 9:55 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:

> 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
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>



-- 
-- 
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>

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Thanks Christian.

Regards
JB

On 02/16/2016 05:42 PM, Christian Schneider wrote:
> According to the discussion and the votes JB summarized we decided to
> roll back my change to use bnd files.
> I removed all bnd files and put the same configs in the poms.
>
> Believe me that I shed a lot of DRY tears when adding 300 lines that do
> absolutely nothing ... but it was a community decision so this is fine
> with me.
> https://github.com/apache/karaf-decanter/commit/009aef25d5b61f71648e58637bb8fb83ed7ca0bf
>
>
> Christian
>
> On 11.02.2016 09:55, 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
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

I actually found a nice way to remove a lot of the overhead again.

I set the default in the parent to not export any packages. Which is a 
good idea in OSGi anyway if you
do not want to have impl or private in the package names.

After the migration to DS (which removed the Activator setting) most of 
the bundle plugin configs just defined the local base package as 
private. So with the new default
I was able to remove the whole plugin in most modules.

https://github.com/apache/karaf-decanter/commit/2855ecfe0c3bba4ed30ce748dc70dca0f76cff60

Christian

On 16.02.2016 17:52, Milen Dyankov wrote:
> *358 additions* and *57 deletions*.
>
> I feel your pain :)
>
>
> On Tue, Feb 16, 2016 at 5:42 PM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> According to the discussion and the votes JB summarized we decided to roll
>> back my change to use bnd files.
>> I removed all bnd files and put the same configs in the poms.
>>
>> Believe me that I shed a lot of DRY tears when adding 300 lines that do
>> absolutely nothing ... but it was a community decision so this is fine with
>> me.
>>
>> https://github.com/apache/karaf-decanter/commit/009aef25d5b61f71648e58637bb8fb83ed7ca0bf
>>
>> Christian
>>
>> On 11.02.2016 09:55, 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
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Milen Dyankov <mi...@gmail.com>]

*358 additions* and *57 deletions*.

I feel your pain :)


On Tue, Feb 16, 2016 at 5:42 PM, Christian Schneider <
chris@die-schneider.net> wrote:

> According to the discussion and the votes JB summarized we decided to roll
> back my change to use bnd files.
> I removed all bnd files and put the same configs in the poms.
>
> Believe me that I shed a lot of DRY tears when adding 300 lines that do
> absolutely nothing ... but it was a community decision so this is fine with
> me.
>
> https://github.com/apache/karaf-decanter/commit/009aef25d5b61f71648e58637bb8fb83ed7ca0bf
>
> Christian
>
> On 11.02.2016 09:55, 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
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
http://about.me/milen

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

According to the discussion and the votes JB summarized we decided to 
roll back my change to use bnd files.
I removed all bnd files and put the same configs in the poms.

Believe me that I shed a lot of DRY tears when adding 300 lines that do 
absolutely nothing ... but it was a community decision so this is fine 
with me.
https://github.com/apache/karaf-decanter/commit/009aef25d5b61f71648e58637bb8fb83ed7ca0bf

Christian

On 11.02.2016 09:55, 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

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Agree,

thanks for dealing with that.

Regards
JB

On 02/16/2016 10:44 AM, Christian Schneider wrote:
> I agree to revert. Let me do it though. As I did the change it is my
> duty to do the revert.
>
> I described in my response to Guillaume how I plan to do the change. I
> would like to avoid
> a full revert as we would loose a lot of good changes.
>
> Christian
>
> On 16.02.2016 09:42, Jean-Baptiste Onofré wrote:
>> 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
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: bnd files in Decanter Project

[Morgan <mo...@gmail.com>]

Christian,

I also saw you used bnd files in the branch you created for the jpa 
example on karaf boot.
Maybe it could be a good idea to change/revert it also?

Regards,
Morgan

On 2016-02-16 10:44, Christian Schneider wrote:
> I agree to revert. Let me do it though. As I did the change it is my 
> duty to do the revert.
>
> I described in my response to Guillaume how I plan to do the change. I 
> would like to avoid
> a full revert as we would loose a lot of good changes.
>
> Christian
>
> On 16.02.2016 09:42, Jean-Baptiste Onofré wrote:
>> 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
>

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

I agree to revert. Let me do it though. As I did the change it is my 
duty to do the revert.

I described in my response to Guillaume how I plan to do the change. I 
would like to avoid
a full revert as we would loose a lot of good changes.

Christian

On 16.02.2016 09:42, Jean-Baptiste Onofré wrote:
> 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

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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

Re: bnd files in Decanter Project

[Markus Rathgeb <ma...@gmail.com>]

I think this was just a copy'n'paste failure, but if you set inherited
and extensions in the parent POM, there is no need to set it in each
project, too.

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

In the change I now did to replace the bnd files I did not set any special
configs in the parent.
Of cause this makes the individual poms a little bit more verbose as you
have to repeat the snippet for the maven-bundle-plugin.
Still I think this is better than using properties. Simply because nothing
strange happens. Each bundle describes clearly what it needs and offer in
OSGi.

I still prefer the bnd files but as we decided to go with the pom config I
strongly prefer this simple style.

Christian

2016-02-17 13:18 GMT+01:00 Łukasz Dywicki <lu...@code-house.org>:

> Since entire thing is going slowly into end I just wanted to clarify one
> statement from Christian’s earier mail:
>
>
> > Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net>
> w dniu 16 lut 2016, o godz. 10:29:
> >
> > On 16.02.2016 08:46, 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.
> > So if I interpret you correctly then we would not set properties in the
> parent pom like Lukasz proposed. I fully agree with you even if it makes
> the configs more verbose.
> > After rereading the example from Lukasz I found that he proposes to set
> the default exports like in Aries to export a package named like the
> groupId which is really bad.
> My proposal was not to use group id as package name but combination of
> group and artifact id which should always give unique namespace of bundle.
> I don’t think we have that in Karaf now (however I didn’t verify that too),
> so it was rather free idea thrown in conversation.
>
> Guillaume - in which cases you noticed different behavior for empty and
> undefined properties? It could be worth for keeping this knowledge for
> future discussions.
>
> Cheers,
> Łukasz
> —
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
>


-- 
-- 
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>

Re: bnd files in Decanter Project

[Łukasz Dywicki <lu...@code-house.org>]

Since entire thing is going slowly into end I just wanted to clarify one statement from Christian’s earier mail:


> Wiadomość napisana przez Christian Schneider <ch...@die-schneider.net> w dniu 16 lut 2016, o godz. 10:29:
> 
> On 16.02.2016 08:46, 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.
> So if I interpret you correctly then we would not set properties in the parent pom like Lukasz proposed. I fully agree with you even if it makes the configs more verbose.
> After rereading the example from Lukasz I found that he proposes to set the default exports like in Aries to export a package named like the groupId which is really bad.
My proposal was not to use group id as package name but combination of group and artifact id which should always give unique namespace of bundle. I don’t think we have that in Karaf now (however I didn’t verify that too), so it was rather free idea thrown in conversation.

Guillaume - in which cases you noticed different behavior for empty and undefined properties? It could be worth for keeping this knowledge for future discussions.

Cheers,
Łukasz
—
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org

Re: bnd files in Decanter Project

[Christian Schneider <ch...@die-schneider.net>]

On 16.02.2016 08:46, 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.
So if I interpret you correctly then we would not set properties in the 
parent pom like Lukasz proposed. I fully agree with you even if it makes 
the configs more verbose.
After rereading the example from Lukasz I found that he proposes to set 
the default exports like in Aries to export a package named like the 
groupId which is really bad.

>
> 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 ?
I checked what instructions are really needed and improved the bnd file 
to just set the minimum settings and leave as much on default as 
possible. That is why they are different.
I agree with you that we need to revert. The current votes like JB wrote 
speak clearly for a revert. I just talked to JB and he thinks we should 
wait one more day though.

As I think a simple revert will not work I would like to summarize what 
I will implement in reverting the bnd file change.


For the parent pom I would set the maven-bundle-plugin like below.
So I would simply remove the include for the bnd file as all other 
settings still make sense.

             <plugin>
                 <groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
                 <inherited>true</inherited>
                 <extensions>true</extensions>
                 <configuration>
                     <instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
                     </instructions>
                 </configuration>
                 <executions>
                     <execution>
                         <id>baseline</id>
                         <goals>
                             <goal>baseline</goal>
                         </goals>
                         <configuration>
<comparisonVersion>${baseline}</comparisonVersion>
<skip>${baseline.skip}</skip>
<failOnError>true</failOnError>
                         </configuration>
                     </execution>
                 </executions>
             </plugin>

For each project I would remove the bnd file containing:
Export-Package: \
     org.apache.karaf.decanter.api,\
     org.apache.karaf.decanter.api.marshaller

and add a maven-bundle-plugin element like this:

     <build>
         <plugins>
             <plugin>
                 <groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
                 <inherited>true</inherited>
                 <extensions>true</extensions>
                 <configuration>
                     <instructions>
                         <Export-Package>
                             org.apache.karaf.decanter.api,
                             org.apache.karaf.decanter.api.marshaller
                         </Export-Package>
                     </instructions>
                 </configuration>
             </plugin>
         </plugins>
     </build>


Is that fine for everyone?

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: bnd files in Decanter Project

[Guillaume Nodet <gn...@apache.org>]

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 <lu...@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 <mo...@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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: bnd files in Decanter Project

[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 <lu...@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 <mo...@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>

Re: bnd files in Decanter Project

[Łukasz Dywicki <lu...@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 <mo...@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
>>> 
>> 
> 

Re: bnd files in Decanter Project

[Morgan <mo...@gmail.com>]

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
>>
>

Re: bnd files in Decanter Project

[Morgan Hautman <mo...@gmail.com>]

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
>

Re: bnd files in Decanter Project

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Achim

Christian proposed that and discussed with me on IRC. You are right: it 
should have been discussed on the mailing list, and it wasn't. I'm very 
sorry about that and I apologize.

For the revert, I would propose to start a discussion thread on the 
mailing list: if we have most of -1 about bnd file usage, then I will 
revert.

Does it sound reasonable to you ?

Thanks,
Regards
JB

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
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com