Re: [VOTE] Release Commons Compress 1.16.1 based on RC1

[Gary Gregory]

+1

Nit:
https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
Since there is only one fix, it should read "Fix Bug", not "Fix Bugs".

>From src zip: ASC, MD5, SHA1 OK.

CLIRR check OK
Apache RAT check OK

Running 'mvn clean package' OK using:

Apache *Maven 3.5.2* (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: *1.7.0_80, vendor: Oracle Corporation*
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: *1.8.0_162, vendor: Oracle Corporation*
Java home: C:\Program Files\Java\jdk1.8.0_162\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: *9.0.4, vendor: Oracle Corporation*
Java home: C:\Program Files\Java\jdk-9.0.4
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

The usual failure on Java 10 in the Surefire Plugin:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test)
on project commons-compress: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.:
NullPointerException -> [Help 1]

Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: *10-ea, vendor: Oracle Corporation*
Java home: C:\Program Files\Java\jdk-10
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
java version "10-ea" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10-ea+40)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10-ea+40, mixed mode)

Gary


On Wed, Feb 7, 2018 at 12:01 AM, Stefan Bodewig  wrote:

> [now with fixed subject line, sorry]
>
> I've again managed to mess up the OSGi manifest with Compress 1.16 so
> this is a quick bug fix release that doesn't contain any code changes.
>
> Apart from the manifest fix I've updated zstd-jni to the latest release
> and added a note about the internal nature of the LZ77Compressor.Block
> class.
>
> Compress 1.16.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/ (svn
> revision 24778)
>
> The tag is here:
> https://git1-us-west.apache.org/repos/asf?p=commons-
> compress.git;a=tag;h=463d3e7bdcd02d84e56559c617ee2307754946b4
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/
> orgapachecommons-1304/org/apache/commons/commons-compress/1.16.1/
>
> These are the Maven artifacts and their sha256 hashes
>
> a20d8e45315abbe07faf952e095817b9925f38c4fc39e8a211c7d072702e97eb
> commons-compress-1.16.1.jar
> 9554efe9767772136113ea8912971706a384de50a60da01a20bbf6e917689d7b
> commons-compress-1.16.1-javadoc.jar
> 0d155b498471fd7744176ecd09599e79e3fca4e8e38ff6d91c2666de89e03f25
> commons-compress-1.16.1-sources.jar
> 1be01dfd51b17a359946647a5b1152748bc8ab4a9a975e287dbdac33123c0a54
> commons-compress-1.16.1-tests.jar
> b3065f7512bd56b56872585cdcbe19dcc4f3691d8d4ed3dbdf5e881cbd40e91b
> commons-compress-1.16.1-test-sources.jar
> 5efe65bb54d680ae9c2b119228d45dcff6363804856d095f32c24ea531ca5d07
> commons-compress-1.16.1.pom
>
> I have tested this with JDK 8 ... using Maven 3
>
> Details of changes since 1.16 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> RELEASE-NOTES.txt
> https://stefan.samaflost.de/staging/commons-compress-1.16.
> 1/changes-report.html
>
> Site:
> https://stefan.samaflost.de/staging/commons-compress-1.16.1/
>
> As usual when I cut a release this is not the site I'm going to
> publish. I'll publish a fresh site from master once the release date
> is known.
>
> The download link and the link to the 1.16.1 javadocs are not expected
> to work.
>
> If you want to build the site yourself, please note the japicmp plugin
> and our parent pom force you to run the package goal first. The magical
> incantation is
>
> mvn clean package site -Pjacoco
>
> japicmp Report (compared to 1.16):
> https://stefan.samaflost.de/staging/commons-compress-1.16.
> 1/japicmp.html
>
> which is empty as there has been no code change at all.
>
> RAT Report:
> https://stefan.samaflost.de/staging/commons-compress-1.16.
> 1/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 07:00 UTC 

Re: [release-plugin] best multi-module project?

[Gilles]

On Wed, 7 Feb 2018 08:31:45 -0500, Rob Tompkins wrote:
On Feb 6, 2018, at 6:28 PM, Gilles  
wrote:


On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote:
On Feb 5, 2018, at 3:05 PM, Gilles  
wrote:


On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote:
On Feb 5, 2018, at 2:22 PM, Gilles 
 wrote:



On Mon, 5 Feb 2018 14:17:18 -0500, Rob Tompkins wrote:
Which should be the template multi-module project? They all 
have

subtle differences that lead to different nuances to the build.


Which differences did you spot?


Nothing of any particular consequence, just where the main 
assemblies

end up. Or which Pom they’re in.


What do you mean by "main assemblies"?  If it's the "full"
distribution, then is it a matter of naming the output directory?
It could be configurable.

For the config, the main POM looks the appropriate place if it can
be done without side-effects. [For RNG I created a separate 
directory

because I was not sure how to do it.]


Right….that’s why I was asking which project would be the best
standard to work from, and then I could go through and take all of 
the

other multi-module builds and mildly refactor the pom/directory
structure to align with which ever we decided was standard.

Is [jcs] the right choice as the standard?


Why this one rather than another?
It's not clear what you are looking for.


It really doesn’t matter too much to me, I just wanted to get a
community consensus on what we think a standard directory structure
should be, or the exemplar
multimodule commons project.


Quite possibly none of them is *the* example to follow.


It’s just easier to work from a specific project as opposed to trying
to generalize immediately.


Perhaps (?) the other way around: by implementing some release
procedure of a multi-module project, you can suggest a matching
layout.

See also my "wish" below. If it could work that way, the layout
does not matter since the module info is taken from the top POM.

Perhaps there could be a profile
---CUT---

  distribution-bundle
  
commons-compX-mod1
commons-compX-mod2
  

---CUT---
And the plugin would go down the named directories and collect
the artefacts.  This would allow a project to contain modules
not yet ready for release.


So my thought right now is either [rng] or [jcs].

I suppose another thought could be: is anyone planning a release on a
commons multi-module project anytime soon?


Yes.


If so which?


"Commons RNG", as soon as the pending issues[1] are resolved:
 * RNG-40
 * RNG-31
 * RNG-48
 * RNG-44

The latter three are related to the multi-module handling by
the "parent" project (i.e. the problem(s) which you intend to
solve IIUC).

Regards,
Gilles

[1] 
https://issues.apache.org/jira/browse/RNG-40?filter=-5=project%20%3D%20RNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1%20order%20by%20priority%20DESC%2Cupdated%20DESC




-Rob


From what I see wrt the creation of "full dist" artefacts, the
difference with e.g. [RNG] is that in [jcs], there is a maven
module, with no code, while for [RNG], there is a directory
(not a maven module), but both contain a POM whose only purpose
is to provide an "assembly" config.

Having no idea on how to achieve it, I'd wish that creating
the "full dist" only requires a custom "goal" like (?)
$ mvn package:dist
with no ad-hoc directory/module: all modules specified in the
top POM would have their artefacts (recursively) bundled into
 -dist-.tar.gz

Regards,
Gilles


Cheers,
-Rob



Gilles


I
figure we pick one and make that the standard multi-module 
build

paradigm and fit the others into it.

-Rob




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 

For additional commands, e-mail: dev-h...@commons.apache.org 




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release-plugin] best multi-module project?

[Rob Tompkins]

> On Feb 6, 2018, at 6:28 PM, Gilles  wrote:
> 
> On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote:
>>> On Feb 5, 2018, at 3:05 PM, Gilles  wrote:
>>> 
>>> On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote:
> On Feb 5, 2018, at 2:22 PM, Gilles  wrote:
> 
>> On Mon, 5 Feb 2018 14:17:18 -0500, Rob Tompkins wrote:
>> Which should be the template multi-module project? They all have
>> subtle differences that lead to different nuances to the build.
> 
> Which differences did you spot?
 
 Nothing of any particular consequence, just where the main assemblies
 end up. Or which Pom they’re in.
>>> 
>>> What do you mean by "main assemblies"?  If it's the "full"
>>> distribution, then is it a matter of naming the output directory?
>>> It could be configurable.
>>> 
>>> For the config, the main POM looks the appropriate place if it can
>>> be done without side-effects. [For RNG I created a separate directory
>>> because I was not sure how to do it.]
>> 
>> Right….that’s why I was asking which project would be the best
>> standard to work from, and then I could go through and take all of the
>> other multi-module builds and mildly refactor the pom/directory
>> structure to align with which ever we decided was standard.
>> 
>> Is [jcs] the right choice as the standard?
> 
> Why this one rather than another?
> It's not clear what you are looking for.

It really doesn’t matter too much to me, I just wanted to get a community 
consensus on what we think a standard directory structure should be, or the 
exemplar 
multimodule commons project.

It’s just easier to work from a specific project as opposed to trying to 
generalize immediately.

So my thought right now is either [rng] or [jcs]. 

I suppose another thought could be: is anyone planning a release on a commons 
multi-module project anytime soon? If so which?

-Rob

> From what I see wrt the creation of "full dist" artefacts, the
> difference with e.g. [RNG] is that in [jcs], there is a maven
> module, with no code, while for [RNG], there is a directory
> (not a maven module), but both contain a POM whose only purpose
> is to provide an "assembly" config.
> 
> Having no idea on how to achieve it, I'd wish that creating
> the "full dist" only requires a custom "goal" like (?)
> $ mvn package:dist
> with no ad-hoc directory/module: all modules specified in the
> top POM would have their artefacts (recursively) bundled into
>  -dist-.tar.gz
> 
> Regards,
> Gilles
> 
>> Cheers,
>> -Rob
>> 
>>> 
>>> Gilles
>>> 
>> I
>> figure we pick one and make that the standard multi-module build
>> paradigm and fit the others into it.
>> 
>> -Rob
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
> 

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  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] cut 1.16.1 very soon?

[Jochen Wiedmann]

On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] cut 1.16.1 very soon?

[Jochen Wiedmann]

On Tue, Feb 6, 2018 at 4:43 PM, Stefan Bodewig  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org