Totally +1 what Neil said. However there is one work around you can take if you really want to open yourself up like that...
http://bnd.bndtools.org/macros/range.html Specifically applied like so: Import-Package: org.apache.wicket.*; version="${range;[6,+)}", * This means use literal '6' as the floor, but increment the ceiling to the next MAJOR version above what's found on the classpath. i.e. if you compiled against 8 then the result would be "[6,8)" The one caveat is I'm not sure how well bnd's macros are handle using the maven-bundle-plugin but you could just try to see what happens - Ray On Thu, Mar 8, 2018 at 11:14 AM, Neil Bartlett <njbartl...@gmail.com> wrote: > Bnd (and by extension the maven-bundle-plugin) uses semantic versions to > infer import ranges, based on the actual version that was compiled against. > If you build against version 8.0.0 of an API then we have no way to know > that you are also compatible with versions 7.0.0 and 6.0.0. > > In fact it would be a violation of semantic versioning if major versions > 6.0.0 through 8.0.0 were actually backwards compatible. > > It's my understanding that most Maven users consider build-time version > ranges to be a bad practice, because your build output could vary wildly > depending on the content of your local repository. See "Should Maven > dependency version ranges be considered deprecated?"[1] > > Regards, > Neil > > > [1] > https://stackoverflow.com/questions/7167250/should- > maven-dependency-version-ranges-be-considered-deprecated > > On Thu, Mar 8, 2018 at 4:05 PM, Martin Nielsen <mny...@gmail.com> wrote: > > > Hello everyone. > > > > I am trying to make the Maven Bundle Plugin use a version range i have > > defined in the POM of my project. > > Basically a project of mine has a small wicket module which i know works > > through wicket 6-8. So i have defined the following dependency: > > > > <dependency> > > <groupId>org.apache.wicket</groupId> > > <artifactId>wicket-core</artifactId> > > <version>[6.0.0,9.0.0)</version> > > <scope>provided</scope> > > </dependency> > > > > The problem is that the Maven Bundle Plugin doesn't seem to care all that > > much, and i get the following dependency in the manifest: > > > > org.apache.wicket;version="[8.0,9)",org.apache.wicket.ajax; > > version="[8.0,9)",org.apache.wicket.ajax.form;version="[8. > > 0,9)",org.apache.wicket.behavior;version="[8.0,9)", > > org.apache.wicket.markup.html;version="[8.0,9)",org.apache. > > wicket.markup.html.basic;version="[8.0,9)",org.apache. > > wicket.markup.html.form;version="[8.0,9)",org.apache. > > wicket.markup.html.list;version="[8.0,9)",org.apache. > > wicket.markup.html.panel;version="[8.0,9)",org.apache. > > wicket.model;version="[8.0,9)",org.apache.wicket.model.util; > > version="[8.0,9)",org.apache.wicket.request.mapper. > > parameter;version="[8.0,9)",org.apache.wicket.util.string; > > version="[8.0,9)" > > > > My intent was to get a version range matching the maven range, but it > seems > > that the Bundle Plugin just looks at the artifact which was actually > > resolved and uses that, which ends up being [8.0,9). > > > > Is there a way to make the Bundle Plugin parse the POM version range, or > is > > there a fairly none-intrusive way to specify the version for all those > > packages? > > > > > > Thank you > > -Martin > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
