You don't actually have to duplicate anything. The lower bound appears in
two places but that can be handled with a property:
<properties>
<wicket.base.version>6.0.0</wicket.base.version>
</properties>
...
<dependency>
<artifactId>...</artifactId>
<version>${wicket.base.version}</version>
</dependency>
...
<Import-Package>org.apache.wicket.*; version="[${wicket.base.version}, 9)"
On Thu, Mar 8, 2018 at 4:43 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:
> On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
>
> > 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.
> >
>
> The problem with that is that you have to maintain duplicate information
> about the upper bound, while with my solution you can forget the package
> import configuration and just adjust the pom's dependency.
>
> You are of course _assuming_ about the compatibility.
>
> So you have the two options:
>
> 1) Neil - compile against a concrete floor AND have to duplicate the
> information manually
> 2) Ray - compile against the latest, have the information not be dup'd, BUT
> assume backward compatibility
>
> Pick your poison.
>
> We already determined that there is devils in the details w.r.t. the fact
> that Wicket is not semantically versioned.
>
> - Ray
>
>
> > 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)
> > >
> >
>
>
>
> --
> *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)
>
