I know its not exactly bulletproof, but i do have a pax exam test each
wicket major version so it is tested against wicket 6-8 on each build.
But i agree that it is poisonous on large projects, but in this case it is
narrow and testable and i don't want to lock the plugin to a specific
wicket version if I dont have to.
Concerning major versions in maven it is true that a major version signals
an api break somewhere, but if it isn't a part I use I think it should be
ok.
Thanks alot for your swift help and input:)
On 8 Mar 2018 19:05, "Raymond Auge" <raymond.a...@liferay.com> wrote:
I concede the point! :)
- Ray
On Thu, Mar 8, 2018 at 12:49 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
> 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)
> >
>
--
*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)
