Re: [jbosstools-dev] Required bundles and version restriction

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.

-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...) On 4. 10. 2013, at 17:48, Nick Boldt <nboldt(a)redhat.com&gt; 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.re... >> 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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev