If you're going to do this I would recommend instead building against the
floor version 6.0.0 (i.e. <version>6.0.0</version> in the dependency
section of the pom) and overriding the Import-Package with a simpler rule
as follows:
<Import-Package>
org.apache.wicket.*; version="[6, 9)"
</Import-Package>
Building against version 6 will ensure that you do not accidentally use
bits of API from Wicket 7+ in your code, which could then result in errors
like NoSuchMethodError, making your users sad.
Neil
On Thu, Mar 8, 2018 at 4:24 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:
> 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)
>
