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
