aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: [Proposal] Use release per subproject for blueprint
Date Wed, 04 Jan 2017 16:13:08 GMT
I would +1 the general sentiment of Felix here.

I also think if the root problem is test framework doesn't properly handle
using the most recent code from peer projects then that is the thing that
is broken...

I generally agree that bundle version should have some semantic meaning.

Also my 2cents.

- Ray

On Jan 4, 2017 09:42, "Felix Meschberger" <fmeschbe@adobe.com> wrote:

> Hi
>
> Sorry ahead for getting somewhat PITA ...
>
> > Am 03.01.2017 um 20:04 schrieb Christian Schneider <
> chris@die-schneider.net>:
> >
> > The motivation for releasing the bundles together is that it makes life
> > easier for maintainers as well as users. The maintainer can do the
> complete
> > release in one step.
>
> As a user I don’t care for that. As a maintainer I bite the bullet to make
> life for the user easier.
>
> > The user can just combine the bundles with the same
> > version and knows they work together.
>
> As a user I trust the Import-Package instructions to ensure this
> cooperation. Any other „work together“ dependency not declared by
> Import-Package or a generic Capability/Requirement pair, IMHO is very much
> not OSGi.
>
> > It is also good for the developers as
> > the tests always use the newest bundles. So tests always cover the newest
> > changes. In current aries tests we often find at some point that tests
> > still use the old versions and so are not covering errors in current
> code.
>
> Sorry to be blunt, this sounds like solving for lazyness.
>
> >
> > In OSGi the bundle version does not mean much the important version is on
> > the package.
>
> True. My remark was more from the POV of a human encountering V1 and V2 of
> a bundle and assuming there is a change. If there is none, I would be
> confused.
>
> > So if we upgrade package versions using semantic versioning we
> > should not have a problem with compatibility at runtime.
> > By cleverly using the package versions we still can assure that more
> > advanced users can upgrade individual bundles and keep others the same.
> > Especially user code will be very compatible if we do not change package
> > versions when there are no changes.
>
> Oh, I assume the bundles are already configured like that ;-)
>
> If you export packages with their bundle versions, you would be doing
> something wrong anyway. Not looking at the source right now, but I assume
> this is not the case.
>
> >
> > We already have some examples where this works very well like Aries RSA.
> > See
> > https://github.com/apache/aries-rsa/blob/master/spi/src/
> main/java/org/apache/aries/rsa/spi/packageinfo
> > The bundles are all released together. Still the spi package which is the
> > most important dependency accross modules (besides the rsa spec) is still
> > at 1.0.0. So while the bundle versions increased with every release we
> > still can combine bundles from different releases at runtime without any
> > problems.
>
> Great. This is exactly how it works for package versions: Package versions
> are for the OSGi framework to wire bundles. Semantic versioning applied.
> Bundle versions are for humans. It would be great to apply semantic
> versioning here as well to some extent. Though not in a technically strict
> sense. Still no change, no version IMHO is a good thing.
>
> Regards
> Felix
>
> >
> > Christian
> >
> >
> >
> > 2017-01-03 14:04 GMT+01:00 Felix Meschberger <fmeschbe@adobe.com>:
> >
> >> Hi Christian
> >>
> >> On a high level I disagree and would suggest to continue releasing
> >> individual bundles.
> >>
> >> Plus: don’t blindly update dependency versions just because there is a
> new
> >> release.
> >>
> >> I think the „plus“ is actually key here: With OSGi applications are
> bound
> >> late at the time of deployment using the wiring „instructions“ such as
> >> Import-Package and Export-Package. This is the essential dependency
> >> management for bundles.
> >>
> >> The build time dependencies really are just that: build time. So unless
> >> the build (the actual code, not necessairily the tests) don’t need any
> >> newly released features, it is actually better to *not* update the
> >> dependencies. Because this allows to update individual bundles more
> >> independently at deployment time.
> >>
> >> If there are requirements, then updating makes sense. But other than
> >> bundles implementing new API or bundles using new API, I fail to see any
> >> need for such updates.
> >>
> >> There is another one: In OSGi „projects“ bundles generally evolve
> >> independently. Releasing them in lock-step might/will create new
> versions
> >> of bundles which have not actually changed. What does the new version
> then
> >> purvey ? Nothing, at best it would be confusing.
> >>
> >> Just my $.02
> >>
> >> Regards
> >> Felix
> >>
> >>
> >>> Am 03.01.2017 um 12:34 schrieb Christian Schneider <
> >> chris@die-schneider.net>:
> >>>
> >>> Currently the blueprint bundles are released individually. I think this
> >> creates a lot of overhead as there are quite many bundles and for each
> >> release you have to manually update the dependencies in several places.
> I
> >> am also sure that we quite regularly forgot to update dependencies. For
> >> example the blueprint-repository project was not updated for any recent
> >> releases.
> >>>
> >>> So I propose we change the blueprint subproject to always release all
> >> bundles and keep the bundle versions aligned. We should still be able to
> >> make the project very stable by using package versions for the APIs.
> >>>
> >>> A side effect would be that we could have blueprint karaf features and
> >> an OBR repository for other non karaf deployments in the aries blueprint
> >> code and the maintenance would be quite low.
> >>>
> >>> So what do you think?
> >>>
> >>> Christian
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> http://www.talend.com
> >>>
> >>
> >>
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
> 46&URL=http%3a%2f%2fwww.liquid-reality.de>
> >
> > Open Source Architect
> > http://www.talend.com
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
> 46&URL=http%3a%2f%2fwww.talend.com>
>
>

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