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é" <j...@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é <j...@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 <bcanh...@googlemail.com >>>>>>> <mailto:bcanh...@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é >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>> >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
