Re: OSGi Version at Package Level

2017-06-21 Thread Bernd Eckenfels
://bernd.eckenfels.net From: Bertrand Delacretaz Sent: Wednesday, June 21, 2017 9:03:28 AM To: Commons Developers List Subject: Re: OSGi Version at Package Level On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero wrote: > Bundles can specify all sorts of Requireme

Re: OSGi Version at Package Level

2017-06-21 Thread Bertrand Delacretaz
On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero wrote: > Bundles can specify all sorts of Requirements, including implementations, > and bugfix version ranges...It can be a > little too expressive :-)... Yes, in the OSGi projects where I'm involved we avoid these things as they create more coup

Re: OSGi Version at Package Level

2017-06-20 Thread Gary Gregory
On Jun 20, 2017 3:08 PM, "Simon Spero" wrote: On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig wrote: > > Interesting. This means OSGi only provides a way for consumers to say > which version of an API they want, but not which implementation. This means > as a consumer you can't say "I want ver

Re: OSGi Version at Package Level

2017-06-20 Thread Simon Spero
On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig wrote: > > Interesting. This means OSGi only provides a way for consumers to say > which version of an API they want, but not which implementation. This means > as a consumer you can't say "I want version 1.19 of Compress because I know > it contai

Re: OSGi Version at Package Level

2017-06-20 Thread Stefan Bodewig
On 2017-06-20, Bertrand Delacretaz wrote: > On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig wrote: >> ...We use the default configuration of the bundle plugin, only marking some >> imports as optional. So we are exporting all our packages... > Ok. In the OSGi world it's only APIs and utility cla

Re: OSGi Version at Package Level

2017-06-20 Thread Bertrand Delacretaz
Hi Stefan, On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig wrote: > ...We use the default configuration of the bundle plugin, only marking some > imports as optional. So we are exporting all our packages... Ok. In the OSGi world it's only APIs and utility classes that should be exported, impleme

Re: OSGi Version at Package Level

2017-06-15 Thread Stefan Bodewig
On 2017-06-12, Bertrand Delacretaz wrote: > I'll do my best to answer from my heavy OSGi user's point of view - > but as mentioned I know little about the specifics of Compress. Thanks, Bertrand. You don't really need to know specifics about Compress. It contains some packages that provide the ge

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-13 Thread Simon Spero
On Jun 13, 2017 1:48 PM, "Gary Gregory" wrote: I think that the best way to see how this works is to provide a patch... then we can see how it goes. Gary- Can you clarify a few things: What would you like to see patches for - the commons parent / related mojo one or more commons projects, t

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-13 Thread Gary Gregory
I think that the best way to see how this works is to provide a patch... then we can see how it goes. Gary On Mon, Jun 12, 2017 at 10:18 AM, Simon Spero wrote: > On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker wrote: > > > I'd love to have a semantic versioning plugin like that which can suggest

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-12 Thread Simon Spero
On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker wrote: > I'd love to have a semantic versioning plugin like that which can suggest > what the version number is for the entire project. Elm (programming > language) has a tool like that, and it works rather well in practice (even > though there are so

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-12 Thread Simon Spero
On Sun, Jun 11, 2017 at 7:37 PM, Gary Gregory wrote: > Is one upshot of this is that we should base the version number based on > this OSGi report tool? > There are a few choices so the SEF upshot selector

Re: OSGi Version at Package Level

2017-06-12 Thread Bertrand Delacretaz
Hi Stefan, I'll do my best to answer from my heavy OSGi user's point of view - but as mentioned I know little about the specifics of Compress. On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig wrote: > ...Say we started versioning packages with 1.15 and all untouched APIs stay > at 1.14. We update

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-12 Thread Matt Sicker
I'd love to have a semantic versioning plugin like that which can suggest what the version number is for the entire project. Elm (programming language) has a tool like that, and it works rather well in practice (even though there are some popular libraries that are at version 5.0.0 already because

Re: OSGi Version at Package Level

2017-06-12 Thread Stefan Bodewig
On 2017-06-07, Bertrand Delacretaz wrote: > On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg wrote: >> ...Do I understand well that we would have to micro manage versions at the >> package level different from the version at the component level, and >> sometimes significantly different versions (li

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-11 Thread Gary Gregory
Is one upshot of this is that we should base the version number based on this OSGi report tool? Gary On Jun 11, 2017 1:58 PM, "Simon Spero" wrote: > On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory > wrote: > > > My POV is that I only see a possible use cases for this in multi-module > > componen

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-11 Thread Simon Spero
On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory wrote: > My POV is that I only see a possible use cases for this in multi-module > components where one module defines an API and others different > implementation. Our release process is enough of a pain. Asking everyone > to consider if a change war

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-11 Thread Emmanuel Bourg
Le 11/06/2017 à 21:16, Gary Gregory a écrit : > Can you show us a real problem that this would have solved? +1, I don't understand what actual issue it would solve with commons-compress. Emmanuel Bourg - To unsubscribe, e-mail:

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-11 Thread Gary Gregory
My POV is that I only see a possible use cases for this in multi-module components where one module defines an API and others different implementation. Our release process is enough of a pain. Asking everyone to consider if a change warrants a package version change is a pain. I still do not see wh

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-11 Thread Simon Spero
So what's the current thinking on using compatibility-verified package versioning (for commons-* in general, but COMPRESS-399 in particular?) It doesn't take much work, and incorrect package versions cause real problems. *You added the headers and here I am. You tell 'em I'M coming... and Jar H

Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-07 Thread Gary Gregory
On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero wrote: > As Bertrand mentioned earlier, the bundle:baseline goal is built in to the > maven-bundle-plugin already in use! > > The pull-request adds that goal to the verify phase of the maven build (and > changes the travis config to run 'mvn verify'

OSGI Version at Package Level : some more details about the COMPRESS-399 pull request

2017-06-07 Thread Simon Spero
As Bertrand mentioned earlier, the bundle:baseline goal is built in to the maven-bundle-plugin already in use! The pull-request adds that goal to the verify phase of the maven build (and changes the travis config to run 'mvn verify' instead of 'mvn test' ). The baseline goal is set to fail the b

Re: OSGi Version at Package Level

2017-06-07 Thread Gilles
On Wed, 7 Jun 2017 10:54:54 +0100, sebb wrote: On 7 June 2017 at 09:02, Bertrand Delacretaz wrote: On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg wrote: Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit : ... Implementing semantic versioning at the java package level as opposed to bundle le

Re: OSGi Version at Package Level

2017-06-07 Thread sebb
On 7 June 2017 at 09:02, Bertrand Delacretaz wrote: > On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg wrote: >> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit : >>>... Implementing semantic versioning at the java package level as opposed >>> to bundle level. >> >> That's the theory, I'm actuall

Re: OSGi Version at Package Level

2017-06-07 Thread Bertrand Delacretaz
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg wrote: > Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit : >>... Implementing semantic versioning at the java package level as opposed >> to bundle level. > > That's the theory, I'm actually curious to see what real issue it solves > with commons-co

Re: OSGi Version at Package Level

2017-06-07 Thread Emmanuel Bourg
Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit : > With the right tools as mentioned in my previous message it's quite easy. Easier but not easy. > Implementing semantic versioning at the java package level as opposed > to bundle level. That's the theory, I'm actually curious to see what re

Re: OSGi Version at Package Level

2017-06-07 Thread Bertrand Delacretaz
On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg wrote: > ...Do I understand well that we would have to micro manage versions at the > package level different from the version at the component level, and > sometimes significantly different versions (like foo 1.2.3 and > org.apache.commons.foo.bar 2.

Re: OSGi Version at Package Level

2017-06-07 Thread Emmanuel Bourg
Le 7/06/2017 à 02:10, Jörg Schaible a écrit : > Your opinions? Do I understand well that we would have to micro manage versions at the package level different from the version at the component level, and sometimes significantly different versions (like foo 1.2.3 and org.apache.commons.foo.bar 2.3

Re: OSGi Version at Package Level

2017-06-06 Thread Bertrand Delacretaz
Hi, On Wed, Jun 7, 2017 at 2:10 AM, Jörg Schaible wrote: > ...maybe you have missed the discussion for > https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a > PR that introduces individual versions at package level for a component That's standard practice for OSGi bund

Re: OSGi Version at Package Level

2017-06-06 Thread Gary Gregory
On Tue, Jun 6, 2017 at 5:10 PM, Jörg Schaible wrote: > Hi, > > maybe you have missed the discussion for > https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a > PR that introduces individual versions at package level for a component. > > Actually I can understand the reasoni

OSGi Version at Package Level

2017-06-06 Thread Jörg Schaible
Hi, maybe you have missed the discussion for https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a PR that introduces individual versions at package level for a component. Actually I can understand the reasoning from a logical point if view, but it fails for me completely