karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Daniel <david.daniel.1...@gmail.com>
Subject Re: bnd files in Decanter Project
Date Thu, 11 Feb 2016 23:14:35 GMT
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 <bcanhome@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
> > > >>>>>> <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
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > > --
> > > > 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
> >
>

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