I agree that Martin has probably done the right thing... even having tested
the various versions, which is above and beyond what most developers would
bother to do.
My criticism is aimed at the Wicket developers who have misused versions
and forced Martin to do all this extra work!
Regards,
Neil
On Fri, Mar 9, 2018 at 5:57 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:
> 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
>
