You’re right, with Import-Package you are free to rearrange the packages over
time. However, if the package are not versioned properly then when the package
moves to another bundle it can suddenly have a lower, higher, or same version.
So the consumer of the version will be fooled.
Garbage in -> Garbage out
Kind regards,
Peter Kriens
> On 10 aug. 2015, at 11:56, erwindl0 <erwin...@gmail.com> wrote:
>
> That's an interesting perspective.
>
> I was considering the choice of using Require-Bundle versus using
> Import-Package, more in the context of allowing the provider to rearrange
> packages in different bundles, across time. Not in the context of versioning.
>
> thanks
> erwin
>
> Op 10/08/2015 om 11:14 schreef Peter Kriens:
>> What value does the consumer have when the provider ignores semantic
>> versioning? You might then (accidentally) resolve but what would it mean? If
>> you repeat this over a large number of bundles you just created a lot of
>> work without any benefit.
>>
>> If the provider does not use package exports, it is easier to use
>> Require-Bundle because the package versions are then just busy work imho.
>>
>> Therefore, in my world it be a deterioration if we made the bundle version
>> the default (I think this was a very bad decision in the bundle plugin). You
>> would imply some semantics that actually do not exist. Again, if you have a
>> single build that creates all artifacts then your model works, but having no
>> package versions would also work just as well.
>>
>> But don’t let me stop you, bnd supports what you want:
>>
>> Bundle-Version: 4.1
>> -includeresource: classes
>> -exportcontents: *;version=${Bundle-Version}
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>> On 10 aug. 2015, at 10:53, erwindl0 <
>>> <mailto:erwin...@gmail.com>erwin...@gmail.com <mailto:erwin...@gmail.com>>
>>> wrote:
>>>
>>> Hi Peter,
>>>
>>> Thank you for your detailed reply. I also feel the OSGi versioning approach
>>> is stronger than e.g. the maven approach.
>>> Maven is all about their "artifacts" (jars), and when combining this with
>>> their snapshot/release and their pom/parent-pom systems, ends up being very
>>> limiting and complex.
>>>
>>> On the other hand, if for whatever reason an Export-Package does not
>>> specify a version, the current default behaviour seems to consider this as
>>> a "0.0.0"/unspecified.
>>> So an Import-Package statement can not set a version either, or it won't
>>> resolve.
>>>
>>> Which means that when the provider is not sufficiently strict in its
>>> manifest, the consumer side is also forced to forget about versioning
>>> constraints...
>>>
>>> Wouldn't it be an improvement to use the bundle version as "default" value
>>> for exported packages with unspecified versions?
>>> That would still allow the conscious people to follow all good practices
>>> completely, while also easying the entry from more "maven-based" thinking
>>> into the world of OSGI ;-)
>>> I.e. they could already start working with clear dependency mgmt,
>>> Import-Packages with versions etc.
>>>
>>> kind regards
>>> erwin
>>>
>>> Op 07/08/2015 om 15:12 schreef Peter Kriens:
>>>> Package versioning allows you to do semantic versioning, when you use the
>>>> bundle version as package you’re just wasting manpower and CPU cycles
>>>> since there is no benefit.
>>>>
>>>> In OSGi, semantic versioning is a powerful tool because it allows you to
>>>> significantly minimize the amount of work you have to do for minor
>>>> changes. In contrast with maven, the OSGi package model with semantic
>>>> version does not require changes in the metadata whenever there is a small
>>>> change in a dependency because the semantic version signals if that change
>>>> is compatible or not.
>>>>
>>>> If you version all packages with a bundle version you are not telling
>>>> anything about those packages compatibility anymore. If you want to signal
>>>> anything, you should at least take the maximum change of any of its
>>>> constituent packages. So now whenever you make a major change for one
>>>> package, all packages are major changed.
>>>>
>>>> Then again, if you use maven it is already impossible to take the benefits
>>>> of semantic versioning during development time because maven creates a
>>>> rigid hard coded graph. I.e. if a dependency changes, however minor, all
>>>> upstream dependees must adjust their pom. That is partly why releasing on
>>>> maven is so hard, you need to change all metadata when you go from
>>>> snapshot to release.
>>>>
>>>> So it all depends. If you have a single build and all gets build together,
>>>> who cares about package versions? Only if you share binaries with others
>>>> are package versions important. However, there is more than just package
>>>> versions, you also have to follow the architectural rules.
>>>>
>>>> Semantic versioning in OSGi shines if you follow the best practice in
>>>> software engineering. You use small cohesive bundles that are coupled via
>>>> services. Since services have a well defined contract you can then
>>>> semantically version the contract. The advantages of this model are
>>>> tremendous but you need to have experienced it to believe it :-(
>>>>
>>>> That said, I know how hard it is to achieve that level in most software
>>>> organizations. Codebases are more often than not highly coupled monsters.
>>>> Management rarely understands what causes the costs. And developers
>>>> usually prefer to spend umpteen hours to prevent getting a budget for
>>>> doing it right.
>>>>
>>>> So, best of luck! :-)
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On 6 aug. 2015, at 21:16, Endo Alejandro <
>>>>> <mailto:alejandro.e...@grassvalley.com>alejandro.e...@grassvalley.com
>>>>> <mailto:alejandro.e...@grassvalley.com>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I understand all the disadvantages of using require-bundle over
>>>>> import-package, but I’m not sure what’s the effect of using the bundle
>>>>> version as exported package version, at least by default (i.e. when need
>>>>> it, we can create the “packageinfo” file manually to control the package
>>>>> version by hand). I am having a hard time enforcing the usage of
>>>>> packageinfo files in my team. I created a packageinfo file for every
>>>>> exported package but whenever we create new packages we forget to create
>>>>> the file or, what’s worse, when modifying code we forget to bump the
>>>>> package version; so we might end up with problems where a bundle with a
>>>>> bugfix ends up exporting a package with the same version as the buggy
>>>>> package so the fix might or might not work in some systems. Would it be
>>>>> acceptable to, by default, version packages with the bundle version? This
>>>>> is what the maven-bundle-plugin does when there’s no packageinfo anyway.
>>>>> Also, the bundle version is much more visible since we use maven and the
>>>>> maven-release-plugin, which bumps the bundle version itself so we are
>>>>> sure two released bundles will never have the same version therefore
>>>>> neither would the packages.
>>>>>
>>>>> This sounds better than using Require-bundle since we can still for
>>>>> example refactor a bundle without redeploying the consumers. But is it
>>>>> still ok? One drawback I see is complexifying (i.e. slowing down)
>>>>> wiring/start-up due to the (unnecessary) number of exporters of packages
>>>>> that might actually contain the
>>>>> same code.
>>>>>
>>>>> We are using the maven-bundle-plugin. For now bndtools is not an option.
>>>>> Ultimately what I think is the best solution is to start using the
>>>>> baselining feature of bnd, but until then, is versioning all packages in
>>>>> a bundle with the bundle-version problematic??
>>>>>
>>>>>
>>>>> Thanks for any insight,
>>>>>
>>>>> Alejandro
>>>>>
>>>>>
>>>>> DISCLAIMER: Privileged and/or Confidential information may be contained
>>>>> in this message. If you are not the addressee of this message, you may
>>>>> not copy, use or deliver this message to anyone. In such event, you
>>>>> should destroy the message and kindly notify the sender by reply e-mail.
>>>>> It is understood that opinions or conclusions that do not relate to the
>>>>> official business of the company are neither given nor
>>>>> endorsed by the company. Thank You.
>>>>>
>>>>> _______________________________________________
>>>>> OSGi Developer Mail List
>>>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
