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)
