karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: bnd files in Decanter Project
Date Fri, 12 Feb 2016 07:38:09 GMT
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
>>>>>>> <mailto:bcanhome@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
>

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