On this case I agree with Martin, there's a decision to be made to either
violate DRY or SEMANTIC versioning.. For me DRY wins over SEMANTIC as he
would have to 99.999% equal project with the only thing different being the
wicket version.
regards Nino
On Thu, Mar 8, 2018 at 9:56 PM, Martin Nielsen <mny...@gmail.com> wrote:
> 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)
>
--
Best regards / Med venlig hilsen
Nino Martinez
