Re: Can you make the maven bundle plugin use maven version ranges?

[Neil Bartlett]

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  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"  wrote:
> >
> > I concede the point! :)
> >
> > - Ray
> >
> >
> > On Thu, Mar 8, 2018 at 12:49 PM, Neil Bartlett 
> > wrote:
> >
> > > You don't actually have to duplicate anything. The lower bound appears
> in
> > > two places but that can be handled with a property:
> > >
> > > 
> > > 6.0.0
> > > 
> > >
> > > ...
> > >
> > > 
> > > ...
> > > ${wicket.base.version}
> > > 
> > >
> > > ...
> > >
> > > org.apache.wicket.*; version="[${wicket.base.version},
> > 9)"
> > >
> > >
> > >
> > > On Thu, Mar 8, 2018 at 4:43 PM, Raymond Auge  >
> > > wrote:
> > >
> > > > On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett  >
> > > > wrote:
> > > >
> > > > > If you're going to do this I would recommend instead building
> against
> > > the
> > > > > floor version 6.0.0 (i.e. 6.0.0 in the
> dependency
> > > > > section of the pom) and overriding the Import-Package with a
> simpler
> > > rule
> > > > > as follows:
> > > > >
> > > > > 
> > > > > org.apache.wicket.*; version="[6, 9)"
> > > > > 
> > > > >
> > > > > 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 

Re: Can you make the maven bundle plugin use maven version ranges?

[Raymond Auge]

I concede the point! :)

- Ray

On Thu, Mar 8, 2018 at 12:49 PM, Neil Bartlett  wrote:

> You don't actually have to duplicate anything. The lower bound appears in
> two places but that can be handled with a property:
>
> 
> 6.0.0
> 
>
> ...
>
> 
> ...
> ${wicket.base.version}
> 
>
> ...
>
> org.apache.wicket.*; version="[${wicket.base.version}, 9)"
>
>
>
> On Thu, Mar 8, 2018 at 4:43 PM, Raymond Auge 
> wrote:
>
> > On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett 
> > wrote:
> >
> > > If you're going to do this I would recommend instead building against
> the
> > > floor version 6.0.0 (i.e. 6.0.0 in the dependency
> > > section of the pom) and overriding the Import-Package with a simpler
> rule
> > > as follows:
> > >
> > > 
> > > org.apache.wicket.*; version="[6, 9)"
> > > 
> > >
> > > 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  >
> > > 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  >
> > > > 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 
> > > 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:
> > > > > >
> > > > > > 
> > > > > >   org.apache.wicket
> > > > > >   wicket-core
> > > > > >   [6.0.0,9.0.0)
> > > > > >   provided
> > > > > > 
> > > > > >
> > > > > > 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.
> > > > > > 

Re: Can you make the maven bundle plugin use maven version ranges?

[Neil Bartlett]

You don't actually have to duplicate anything. The lower bound appears in
two places but that can be handled with a property:


6.0.0


...


...
${wicket.base.version}


...

org.apache.wicket.*; version="[${wicket.base.version}, 9)"



On Thu, Mar 8, 2018 at 4:43 PM, Raymond Auge 
wrote:

> On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett 
> wrote:
>
> > If you're going to do this I would recommend instead building against the
> > floor version 6.0.0 (i.e. 6.0.0 in the dependency
> > section of the pom) and overriding the Import-Package with a simpler rule
> > as follows:
> >
> > 
> > org.apache.wicket.*; version="[6, 9)"
> > 
> >
> > 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 
> > 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 
> > > 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 
> > 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:
> > > > >
> > > > > 
> > > > >   org.apache.wicket
> > > > >   wicket-core
> > > > >   [6.0.0,9.0.0)
> > > > >   provided
> > > > > 
> > > > >
> > > > > 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.
> > > > > 

Re: Can you make the maven bundle plugin use maven version ranges?

[Raymond Auge]

On Thu, Mar 8, 2018 at 11:37 AM, Neil Bartlett  wrote:

> If you're going to do this I would recommend instead building against the
> floor version 6.0.0 (i.e. 6.0.0 in the dependency
> section of the pom) and overriding the Import-Package with a simpler rule
> as follows:
>
> 
> org.apache.wicket.*; version="[6, 9)"
> 
>
> 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 
> 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 
> > 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 
> 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:
> > > >
> > > > 
> > > >   org.apache.wicket
> > > >   wicket-core
> > > >   [6.0.0,9.0.0)
> > > >   provided
> > > > 
> > > >
> > > > 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é* 

Re: Can you make the maven bundle plugin use maven version ranges?

[Raymond Auge]

On Thu, Mar 8, 2018 at 11:24 AM, Raymond Auge 
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)"
>
> oops, I meant "[6,9)"


>
>
> 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 
> 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  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:
>> >
>> > 
>> >   org.apache.wicket
>> >   wicket-core
>> >   [6.0.0,9.0.0)
>> >   provided
>> > 
>> >
>> > 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é* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Can you make the maven bundle plugin use maven version ranges?

[Raymond Auge]

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  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  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:
> >
> > 
> >   org.apache.wicket
> >   wicket-core
> >   [6.0.0,9.0.0)
> >   provided
> > 
> >
> > 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é* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Can you make the maven bundle plugin use maven version ranges?

[Neil Bartlett]

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  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:
>
> 
>   org.apache.wicket
>   wicket-core
>   [6.0.0,9.0.0)
>   provided
> 
>
> 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
>

Can you make the maven bundle plugin use maven version ranges?

[Martin Nielsen]

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:


  org.apache.wicket
  wicket-core
  [6.0.0,9.0.0)
  provided


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