[compress] cut 1.16.1 very soon?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[compress] cut 1.16.1 very soon?

Stefan Bodewig
Hi

it looks as if I again managed to break the OSGi manifest without
anybody noticing (I'd be the last one to notice):

https://issues.apache.org/jira/browse/COMPRESS-442

If the fix is confirmed I'd like to cut a 1.16.1 release more or less
immediately. Any objections?

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

garydgregory
On Tue, Feb 6, 2018 at 8:43 AM, Stefan Bodewig <[hidden email]> wrote:

> Hi
>
> it looks as if I again managed to break the OSGi manifest without
> anybody noticing (I'd be the last one to notice):
>
> https://issues.apache.org/jira/browse/COMPRESS-442
>
> If the fix is confirmed I'd like to cut a 1.16.1 release more or less
> immediately. Any objections?
>

Sure and you might as well update zstd-jni from 1.3.3-1 to 1.3.3-3.

Gary


> Cheers
>
>         Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

Bruno P. Kinoshita-3
In reply to this post by Stefan Bodewig

>If the fix is confirmed I'd like to cut a 1.16.1 release more or less immediately. Any objections?


+1, go for it. Took me a while to spot the difference between the two lines. Tricky to remember to use := and not = there.

Cheers

B


________________________________
From: Stefan Bodewig <[hidden email]>
To: Commons Developers List <[hidden email]>
Sent: Wednesday, 7 February 2018 4:43 AM
Subject: [compress] cut 1.16.1 very soon?



Hi


it looks as if I again managed to break the OSGi manifest without

anybody noticing (I'd be the last one to notice):


https://issues.apache.org/jira/browse/COMPRESS-442


If the fix is confirmed I'd like to cut a 1.16.1 release more or less

immediately. Any objections?


Cheers


        Stefan


---------------------------------------------------------------------

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

jochen-2
In reply to this post by Stefan Bodewig
On Tue, Feb 6, 2018 at 4:43 PM, Stefan Bodewig <[hidden email]> wrote:

> it looks as if I again managed to break the OSGi manifest without
> anybody noticing (I'd be the last one to notice):

Can't the Felix folks help with that? Perhaps a suitable Maven plugin
for the validate phase. Seems worth a feature request.

Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

Stefan Bodewig
On 2018-02-07, Jochen Wiedmann wrote:

> On Tue, Feb 6, 2018 at 4:43 PM, Stefan Bodewig <[hidden email]> wrote:

>> it looks as if I again managed to break the OSGi manifest without
>> anybody noticing (I'd be the last one to notice):

> Can't the Felix folks help with that? Perhaps a suitable Maven plugin
> for the validate phase. Seems worth a feature request.

I know I asked before (I really am not an OSGi guy at all) and was
pointed into a direction for writing a test that would start a small
container and load the bundle. This should help, but unfortunately the
very idea slipped further and further down my priority list.

Having to cut a new release just because of a missing colon may help
moving it up on said list again :-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

jochen-2
On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig <[hidden email]> wrote:

> I know I asked before (I really am not an OSGi guy at all) and was
> pointed into a direction for writing a test that would start a small
> container and load the bundle. This should help, but unfortunately the
> very idea slipped further and further down my priority list.

Well, if *you* are having trouble here, that's bound to happen for others, too.
And, I don't know how they would implement that, internally, but as it's their
topic, I clearly have the expectation, that *they* provide something useful.

Btw: Would org.apache.felix:maven-bundle-plugin:3.5.0:verify have
spotted the problem?

Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

Stefan Bodewig
On 2018-02-07, Jochen Wiedmann wrote:

> On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig <[hidden email]> wrote:

>> I know I asked before (I really am not an OSGi guy at all) and was
>> pointed into a direction for writing a test that would start a small
>> container and load the bundle. This should help, but unfortunately the
>> very idea slipped further and further down my priority list.

> Well, if *you* are having trouble here, that's bound to happen for
> others, too.  And, I don't know how they would implement that,
> internally, but as it's their topic, I clearly have the expectation,
> that *they* provide something useful.

I'd be content with having a regression test, although I'm not sure how
involved it would get. This time the Import-Package value was
syntactically incorrect, this might get caught by static analysis. Last
time I stripped an Import-Package (the one for XZ when I added the
Brotli dependency IIRC), so the manifest was valid but you have been
unable to use the algorithms provided by XZ. This is a runtime issue
that really requires a test, I guess.

> Btw: Would org.apache.felix:maven-bundle-plugin:3.5.0:verify have
> spotted the problem?

At least not when I use it the naive way (this is based on the rel/1.16
tag:

$ mvn org.apache.felix:maven-bundle-plugin:3.5.0:verify
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Apache Commons Compress 1.16
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-bundle-plugin:3.5.0:verify (default-cli) @ commons-compress ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.625 s
[INFO] Finished at: 2018-02-07T11:04:54+01:00
[INFO] Final Memory: 15M/605M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:3.5.0:verify (default-cli) on project commons-compress: Execution default-cli of goal org.apache.felix:maven-bundle-plugin:3.5.0:verify failed.: NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.

with -X I only get a Maven internal stack trace. Same for the 3.4.0
version that is requested by commons-parent 43.

TBH I don't want to dig deeper here as I really think we need runtime
verification over static analysis.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

Simon Spero
Writing tests for osgi modules is painless... the second time :-P

The key to making tests easy is to use pax-exam, which handles most of the
tedious container setup and junit / test-NG test execution.

https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation

I can implement this if OSGI related changes are wanted.

Simon

On Feb 7, 2018 5:10 AM, "Stefan Bodewig" <[hidden email]> wrote:

> On 2018-02-07, Jochen Wiedmann wrote:
>
> > On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig <[hidden email]>
> wrote:
>
> >> I know I asked before (I really am not an OSGi guy at all) and was
> >> pointed into a direction for writing a test that would start a small
> >> container and load the bundle. This should help, but unfortunately the
> >> very idea slipped further and further down my priority list.
>
> > Well, if *you* are having trouble here, that's bound to happen for
> > others, too.  And, I don't know how they would implement that,
> > internally, but as it's their topic, I clearly have the expectation,
> > that *they* provide something useful.
>
> I'd be content with having a regression test, although I'm not sure how
> involved it would get. This time the Import-Package value was
> syntactically incorrect, this might get caught by static analysis. Last
> time I stripped an Import-Package (the one for XZ when I added the
> Brotli dependency IIRC), so the manifest was valid but you have been
> unable to use the algorithms provided by XZ. This is a runtime issue
> that really requires a test, I guess.
>
> > Btw: Would org.apache.felix:maven-bundle-plugin:3.5.0:verify have
> > spotted the problem?
>
> At least not when I use it the naive way (this is based on the rel/1.16
> tag:
>
> $ mvn org.apache.felix:maven-bundle-plugin:3.5.0:verify
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] Building Apache Commons Compress 1.16
> [INFO] ------------------------------------------------------------
> ------------
> [INFO]
> [INFO] --- maven-bundle-plugin:3.5.0:verify (default-cli) @
> commons-compress ---
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] Total time: 0.625 s
> [INFO] Finished at: 2018-02-07T11:04:54+01:00
> [INFO] Final Memory: 15M/605M
> [INFO] ------------------------------------------------------------
> ------------
> [ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:3.5.0:verify
> (default-cli) on project commons-compress: Execution default-cli of goal
> org.apache.felix:maven-bundle-plugin:3.5.0:verify failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> with -X I only get a Maven internal stack trace. Same for the 3.4.0
> version that is requested by commons-parent 43.
>
> TBH I don't want to dig deeper here as I really think we need runtime
> verification over static analysis.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

garydgregory
You can also look at the log4j-osgi module.
It does some light OSGi testing. I ported the reusable bits to the Commons
Testing got repo.

Gary

On Feb 9, 2018 21:21, "Simon Spero" <[hidden email]> wrote:

> Writing tests for osgi modules is painless... the second time :-P
>
> The key to making tests easy is to use pax-exam, which handles most of the
> tedious container setup and junit / test-NG test execution.
>
> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation
>
> I can implement this if OSGI related changes are wanted.
>
> Simon
>
> On Feb 7, 2018 5:10 AM, "Stefan Bodewig" <[hidden email]> wrote:
>
> > On 2018-02-07, Jochen Wiedmann wrote:
> >
> > > On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig <[hidden email]>
> > wrote:
> >
> > >> I know I asked before (I really am not an OSGi guy at all) and was
> > >> pointed into a direction for writing a test that would start a small
> > >> container and load the bundle. This should help, but unfortunately the
> > >> very idea slipped further and further down my priority list.
> >
> > > Well, if *you* are having trouble here, that's bound to happen for
> > > others, too.  And, I don't know how they would implement that,
> > > internally, but as it's their topic, I clearly have the expectation,
> > > that *they* provide something useful.
> >
> > I'd be content with having a regression test, although I'm not sure how
> > involved it would get. This time the Import-Package value was
> > syntactically incorrect, this might get caught by static analysis. Last
> > time I stripped an Import-Package (the one for XZ when I added the
> > Brotli dependency IIRC), so the manifest was valid but you have been
> > unable to use the algorithms provided by XZ. This is a runtime issue
> > that really requires a test, I guess.
> >
> > > Btw: Would org.apache.felix:maven-bundle-plugin:3.5.0:verify have
> > > spotted the problem?
> >
> > At least not when I use it the naive way (this is based on the rel/1.16
> > tag:
> >
> > $ mvn org.apache.felix:maven-bundle-plugin:3.5.0:verify
> > [INFO] Scanning for projects...
> > [INFO]
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] Building Apache Commons Compress 1.16
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO]
> > [INFO] --- maven-bundle-plugin:3.5.0:verify (default-cli) @
> > commons-compress ---
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] BUILD FAILURE
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] Total time: 0.625 s
> > [INFO] Finished at: 2018-02-07T11:04:54+01:00
> > [INFO] Final Memory: 15M/605M
> > [INFO] ------------------------------------------------------------
> > ------------
> > [ERROR] Failed to execute goal org.apache.felix:maven-bundle-
> plugin:3.5.0:verify
> > (default-cli) on project commons-compress: Execution default-cli of goal
> > org.apache.felix:maven-bundle-plugin:3.5.0:verify failed.:
> > NullPointerException -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the
> > -e switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> >
> > with -X I only get a Maven internal stack trace. Same for the 3.4.0
> > version that is requested by commons-parent 43.
> >
> > TBH I don't want to dig deeper here as I really think we need runtime
> > verification over static analysis.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

Stefan Bodewig
In reply to this post by Simon Spero
On 2018-02-10, Simon Spero wrote:

> Writing tests for osgi modules is painless... the second time :-P

I said I "was pointed into a direction for writing a test ..." that's
been your and Bertrand's input. :-)

> The key to making tests easy is to use pax-exam, which handles most of the
> tedious container setup and junit / test-NG test execution.

> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation

Thanks again.

> I can implement this if OSGI related changes are wanted.

What *I*'d want to see is a regression test that prevents us from
breaking the manifest or dropping imports that used to be there. Others
may want additional OSGI related changes.

https://issues.apache.org/jira/browse/COMPRESS-443

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

garydgregory
In reply to this post by Simon Spero
You can also look at the log4j-osgi module.
It does. It does some load testing for log4j's own budles.
Gary

On Feb 9, 2018 21:21, "Simon Spero" <[hidden email]> wrote:

> Writing tests for osgi modules is painless... the second time :-P
>
> The key to making tests easy is to use pax-exam, which handles most of the
> tedious container setup and junit / test-NG test execution.
>
> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation
>
> I can implement this if OSGI related changes are wanted.
>
> Simon
>
> On Feb 7, 2018 5:10 AM, "Stefan Bodewig" <[hidden email]> wrote:
>
> > On 2018-02-07, Jochen Wiedmann wrote:
> >
> > > On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig <[hidden email]>
> > wrote:
> >
> > >> I know I asked before (I really am not an OSGi guy at all) and was
> > >> pointed into a direction for writing a test that would start a small
> > >> container and load the bundle. This should help, but unfortunately the
> > >> very idea slipped further and further down my priority list.
> >
> > > Well, if *you* are having trouble here, that's bound to happen for
> > > others, too.  And, I don't know how they would implement that,
> > > internally, but as it's their topic, I clearly have the expectation,
> > > that *they* provide something useful.
> >
> > I'd be content with having a regression test, although I'm not sure how
> > involved it would get. This time the Import-Package value was
> > syntactically incorrect, this might get caught by static analysis. Last
> > time I stripped an Import-Package (the one for XZ when I added the
> > Brotli dependency IIRC), so the manifest was valid but you have been
> > unable to use the algorithms provided by XZ. This is a runtime issue
> > that really requires a test, I guess.
> >
> > > Btw: Would org.apache.felix:maven-bundle-plugin:3.5.0:verify have
> > > spotted the problem?
> >
> > At least not when I use it the naive way (this is based on the rel/1.16
> > tag:
> >
> > $ mvn org.apache.felix:maven-bundle-plugin:3.5.0:verify
> > [INFO] Scanning for projects...
> > [INFO]
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] Building Apache Commons Compress 1.16
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO]
> > [INFO] --- maven-bundle-plugin:3.5.0:verify (default-cli) @
> > commons-compress ---
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] BUILD FAILURE
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] Total time: 0.625 s
> > [INFO] Finished at: 2018-02-07T11:04:54+01:00
> > [INFO] Final Memory: 15M/605M
> > [INFO] ------------------------------------------------------------
> > ------------
> > [ERROR] Failed to execute goal org.apache.felix:maven-bundle-
> plugin:3.5.0:verify
> > (default-cli) on project commons-compress: Execution default-cli of goal
> > org.apache.felix:maven-bundle-plugin:3.5.0:verify failed.:
> > NullPointerException -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the
> > -e switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> >
> > with -X I only get a Maven internal stack trace. Same for the 3.4.0
> > version that is requested by commons-parent 43.
> >
> > TBH I don't want to dig deeper here as I really think we need runtime
> > verification over static analysis.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

Oliver Heger-3
In reply to this post by Stefan Bodewig


Am 10.02.2018 um 09:55 schrieb Stefan Bodewig:

> On 2018-02-10, Simon Spero wrote:
>
>> Writing tests for osgi modules is painless... the second time :-P
>
> I said I "was pointed into a direction for writing a test ..." that's
> been your and Bertrand's input. :-)
>
>> The key to making tests easy is to use pax-exam, which handles most of the
>> tedious container setup and junit / test-NG test execution.
>
>> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation
>
> Thanks again.
>
>> I can implement this if OSGI related changes are wanted.
>
> What *I*'d want to see is a regression test that prevents us from
> breaking the manifest or dropping imports that used to be there. Others
> may want additional OSGI related changes.
>
> https://issues.apache.org/jira/browse/COMPRESS-443
>

PaxExam is really a nice tool to write integration tests running inside
the OSGi container. For the purpose at hand it would be possible to
create a setup that starts an embedded OSGi container and deploys the
bundle created by the project. This is not fully trivial because it
requires that all (transitive) dependencies are also installed in the
container.

Such a test checks whether the manifest is more or less syntactically
correct. In order to prove that all packages are correctly exported,
some more tests would have to be written that access the public API.
(Ideally one would run the whole unit test suite in the container, but I
doubt that this would be feasible. Some tests are probably white-box
tests and access internals of a class that are not necessarily available
inside OSGi.)

It would be great to have some generic setup that could be reused by all
Commons components. Maybe another maven plugin? It would require some
functionality of the dependencies plugin to resolve all dependencies,
and of the surefire plugin to run tests.

Oliver

> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [compress] cut 1.16.1 very soon?

garydgregory
On Sat, Feb 10, 2018 at 8:28 AM, Oliver Heger <[hidden email]>
wrote:

>
>
> Am 10.02.2018 um 09:55 schrieb Stefan Bodewig:
> > On 2018-02-10, Simon Spero wrote:
> >
> >> Writing tests for osgi modules is painless... the second time :-P
> >
> > I said I "was pointed into a direction for writing a test ..." that's
> > been your and Bertrand's input. :-)
> >
> >> The key to making tests easy is to use pax-exam, which handles most of
> the
> >> tedious container setup and junit / test-NG test execution.
> >
> >> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/
> 54263870/Documentation
> >
> > Thanks again.
> >
> >> I can implement this if OSGI related changes are wanted.
> >
> > What *I*'d want to see is a regression test that prevents us from
> > breaking the manifest or dropping imports that used to be there. Others
> > may want additional OSGI related changes.
> >
> > https://issues.apache.org/jira/browse/COMPRESS-443
> >
>
> PaxExam is really a nice tool to write integration tests running inside
> the OSGi container. For the purpose at hand it would be possible to
> create a setup that starts an embedded OSGi container and deploys the
> bundle created by the project. This is not fully trivial because it
> requires that all (transitive) dependencies are also installed in the
> container.
>
> Such a test checks whether the manifest is more or less syntactically
> correct. In order to prove that all packages are correctly exported,
> some more tests would have to be written that access the public API.
> (Ideally one would run the whole unit test suite in the container, but I
> doubt that this would be feasible. Some tests are probably white-box
> tests and access internals of a class that are not necessarily available
> inside OSGi.)
>
> It would be great to have some generic setup that could be reused by all
> Commons components. Maybe another maven plugin? It would require some
> functionality of the dependencies plugin to resolve all dependencies,
> and of the surefire plugin to run tests.
>

Please see log4j-osgi and the work in progress in Apache Commons Testing.

Gary


>
> Oliver
>
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>