[jbosstools-dev] Required bundles and version restriction

[Max Rydahl Andersen]

On Thu, Oct 10, 2013 at 02:13:08PM +0200, Martin Malina wrote:
>
>On 10. 10. 2013, at 13:57, Max Rydahl Andersen <manderse at redhat.com> wrote:
>
>> On Thu, Oct 10, 2013 at 12:30:35PM +0200, Martin Malina wrote:
>>> Thanks for the input, guys. I didn't know about the different interpretation of this in feature.xml.
>>> I guess I will stick with the explicit version ranges.
>>> What makes me sad is that I won't be able to use [1] and be done. Every time I upgrade the version I will also have to manually (although I can script it, sure) change all the manifests.
>>
>> eh ?
>>
>> [1] updates all occurence of your project versions - including manifest.
>
>It updates version in manifest of the bundle itself, but not version of required bundles - obviously: it wouldn't know which bundles are part of the same project.
>And the conclusion of this thread is that it probably makes sense for us to keep these requirements strict, including version ranges.
>
>>
>> Aren't your problem about when you  need to update projects that rely on red deer release ?
>
>No, this thread had nothing to do with other projects relying on reddeer - although we could restrict the requirements there, too. But here I was only asking with respect to the reddeer project alone - most reddeer bundles rely on other reddeer bundles.

There really aren't any difference from a project relying on red deer or a component inside red deer relying on another component inside red deer.

But yes, I agree that is not trivial to maintain thus I encourage *less* bundles per "component" and api stability :)

But thats where feature by specifying the version can ensure they at least aren't distributed incompatibly.

Then the bundles can say "use any version", but feature restricts it to a certain one.

This though falls apart if you want to also have the flexibility to split up the feature and just rely on the bundles...then you need to go back
and maintain versions more fine grained.

/max

>-Martin
>
>>
>> Thats where API compatibility becomes relevant ;)
>>
>> /max
>>
>>> -Martin
>>>
>>> [1] mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version> (https://community.jboss.org/en/tools/blog/2011/09/17/coping-with-versions-in-large-multi-module-osgi-projects)
>>>
>>> On 4. 10. 2013, at 17:48, Nick Boldt <nboldt at redhat.com> wrote:
>>>
>>>> It's always better to be explicit, because in plugin manifests "0.4.0" means "0.4.0+" and in feature manifests (feature.xml) it means "[0.4.0,1.0.0)". This is easy to forget, which is why I recommend being explicit, or else bookmarking this blog:
>>>>
>>>> http://divby0.blogspot.ca/2011/07/manifestmf-and-featurexml-versioning.html
>>>>
>>>> :D
>>>>
>>>> On 10/04/2013 09:23 AM, Mickael Istria wrote:
>>>>> On 10/04/2013 02:09 PM, Martin Malina wrote:
>>>>>> in
>>>>>> https://github.com/jboss-reddeer/reddeer/blob/master/plugins/org.jboss.reddeer.eclipse/META-INF/MANIFEST.MF
>>>>> Keep in mind that "0.4.0" means [0.4.0, 2147483647.2147483647.2147483647].
>>>>> Eclipse guidelines say that since only major version bump should cause
>>>>> API incompatibility, it's better to use ranges such as "[0.4.0,1.0.0)"
>>>>> since 1.0.0 and later wouldn't be compatible with 0.x.
>>>>>
>>>>>> The reasoning for this version setting is to eliminate the risk of
>>>>>> mixing different versions of RedDeer bundles that you may have
>>>>>> installed in your local repository. What do you think about this? I
>>>>>> didn't see any such thing in jbosstools source so I wonder if this is
>>>>>> a real threat.
>>>>> On the other end, it prevents any of this bundle to run with older
>>>>> version of RedDeer, even if it's possible to mix them. It's a trade-off
>>>>> between modularity and compatibility
>>>>> As we usually ship bundles in features, and that features contain the
>>>>> exact qualified version of the bundles to install, adding these
>>>>> constraints is not very helpful for the normal installation scenario as
>>>>> features provide much stricter constraints. However, if you don't use
>>>>> feature includes, and only rely on feature "imports" and MANIFEST.MF
>>>>> Require-Bundle to resolve dependencies, such change gives good hints.
>>>>>
>>>>> Anyway, that's a very good question you have there, and there is a very
>>>>> elegant answer in PDE: http://www.eclipse.org/pde/pde-api-tools/ . With
>>>>> API Tools enabled in your IDE, you'll be able to annotate your APIs and
>>>>> PDE will give you hints on how to deal with versions compared to a
>>>>> baseline, depending on the API change you make. Also, if you depend on
>>>>> newer APIs from another bundle, it will tell you to change the version
>>>>> in your dependencies to the minimal version which provides this API.
>>>>>
>>>>> HTH
>>>>> --
>>>>> Mickael Istria
>>>>> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
>>>>> My blog <http://mickaelistria.wordpress.com> - My Tweets
>>>>> <http://twitter.com/mickaelistria>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
>>>>
>>>> --
>>>> Nick Boldt :: JBoss by Red Hat
>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>> http://nick.divbyzero.com
>>>
>>> --
>>> Martin Malina
>>> JBoss QA Engineer
>>> Red Hat Czech s.r.o.
>>> Purkynova 99
>>> 612 45 Brno, Czech Republic
>>>
>>> Tel.: +420 532 294 265
>>>
>>>
>>>
>>>
>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
>--
>Martin Malina
>JBoss QA Engineer
>Red Hat Czech s.r.o.
>Purkynova 99
>612 45 Brno, Czech Republic
>
>Tel.: +420 532 294 265
>
>
>
>