[+1]
Build & tests ok; site & javadoc look good; reports check.
Nits: JIRA report has of issues without a fix version; lots of Checkstyle
warnings; Jacoco coverage is low; old code (Vector...);
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
-Ddoclint=none
On: Apache M
[+1]
Build & tests ok; site & javadoc look good; reports check.
Nits: JIRA report has a few issues without a fix version; Jacoco/coverage is on
the low side;
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
-Ddoclint=none
On: Apache Maven 3.8.6 (84538c9988a25aec085021c3
[+1]
Build & tests ok; site & javadoc look good; reports check.
Nits: JIRA report has lots of issues without a fix version; Jacoco should
exclude parser generated classes;
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On: Apache Maven 3.8.6 (84538c9988a25aec085021c365c
[+1]
Build & tests ok, javadoc & changes ok, reports ok (nit: checkstyle 365 errors,
probably the same on each file).
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On: mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestr
[+1]
Build & tests ok, javadoc looks good, site & reports are functional.
No deal breaker, 3 nits:
- the 1.4 release notes are not accessible fro anywhere but changes report
contains almost same info;
- spotbugs & taglist reports could benefit from a closer look;
- some coverage may be improved
[+1] cancel.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[+1]
Build & test ok; site - javadoc, reports, changes, release notes - look good.
Buit with:
mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_432,
Ack cancel RC1.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[+1]
Build & tests ok; site & javadoc looks good; changes & release history checked;
jira report (nit: a few issues remain no fix version);
Jacoco/Spotbugs/Checktyle, no issues.
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
mvn -version
Apache Maven 3.8.6 (84538c9988
[+1]
Build & tests ok, reports look good (nice coverage), release history
informative.
Built with: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
Using: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.
[+1]
Build & test ok; site & javadoc ok; reports look good.
Built with: mvn clean site -s "$HOME/.m2/commons-settings.xml"
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_432, vendor: Azul Systems, Inc., runti
My [+1]
Builds & tests ok, reproductible build check, reports ok, changes ok.
Checked on:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home:
/Users/hbiestro/Java/apache-maven-3.8.6 Java version: 21.0.3, vendor: Azul
Systems, Inc., runtime:
/Library/Java/JavaVirtualMachin
My [+1]
Builds &tests ok, reproductible build check, reports ok (no coverage by default
?), changes ok.
Checked on:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 21.0.3, vendor: Azul Systems, Inc., runtime:
/Libr
[+1]
Build & tests ok, site & API look good, changes & reports are clean (very nice
coverage).
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java versio
[+1]
With a little caveat that's probably due to segregating building 1.x and 2.x,
the site release notes, changes and API links aren't completely proper.
Built from git clone with:
mvn clean install site -s "$HOME/.m2/commons-settings.xml"
Using:
mvn -version
Apache Maven 3.8.6 (84538c9988a25a
[+1]
With a little caveat that's probably due to segregating building 1.x and 2.x,
the site release notes, changes and API links aren't proper.
Built from git clone with:
mvn clean install site -s "$HOME/.m2/commons-settings.xml"
Using:
mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c36
[+1]
Site & API looks good, release notes / changes correctly reflected, clean
report (nice coverage).
Sigte/build produced with:
mvn clean install site -s "$HOME/.m2/commons-settings.xml"
Using:
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_432, vendor: Azul Systems, I
rch: "aarch64", family: "mac"
hbiestro@D3CC9YTYXF-Henri-Biestro commons-collections-4.5.0-M3-RC1 %
Cheers,
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[+1]
Build & tests ok, reports & changes are clean (nice coverage), site & javadoc
look good.
Built using 'mvn clean install site -s "$HOME/.m2/commons-settings.xml"' on:
mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.
[ +1 ]
Build & tests ok, javadoc ok with correct version, reports look nice, release
notes/change look great.
Using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
J
[ +1 ]
Builds & tests, project reports look good, site ok, nice documentation
( +1, no added dependency :-) ).
Built using:
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_432, vendor: Azul Systems, Inc., runtime:
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home
>
> It does not make sense to me to add any dependency (regardless of
> size) for such minor simplifications.
>
[ +1 ]
Adding a dependency should be done out of functional necessity, not to avoid
one-liners and shading should only be used as the last possible solution.
In the context of the
ro/Java/apache-maven-3.8.6
Java version: 21.0.3, vendor: Azul Systems, Inc., runtime:
/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "Mac&qu
[+1]
Builds ok, site looks good, javadoc ok, reports ok.
- Using:
mvn clean install site -s "$HOME/.m2/commons-settings.xml"
- On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Azul Systems, Inc
[ +1 ]
Build & tests ok, javadoc ok, reports look good (nice coverage), site looks
nice.
Built using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8
[ +1 ]
Using: mvn clean install site -s "$HOME/.m2/commons-settings.xml"
Site looks good, Javadoc ok, reports ok (nit: Spotbugs may need some attention).
Build with:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8
[ +1 ]
Builds & tests ok, site reports clean (nice coverage btw), site - including
release notes & javadoc - look ok.
Built using : mvn clean install site -s "$HOME/.m2/commons-settings.xml"
On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apa
[+1]
Builds and tests ok, site looks good, reports show no issues (nit: code
coverage need some love, JIRA report too).
Built with: mvn -P jacoco -P japicmp clean install site -s
~/.m2/commons-settings.xml
Using: mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven h
[ +1 ]
Builds and tests ok; site and Javadoc look good, reports are ok (commendable
coverage btw, nit JIRA report with no version and Tag List report shows a lot
of todo/fixme/etc).
Built using: mvn -P jacoco -P japicmp clean install site -s
~/.m2/commons-settings.xml
With JDK:
openjdk version
[ +1 ]
Builds & tests ok (nit: verbose output), site & Javadoc look good, reports look
ok (nit: checkstyle & spotbugs need a bit of love, so does Jacoco - coverage is
low).
Nit: Overview page does not mention 1.3.2 nor 1.3.3.
Build using: mvn -P jacoco -P japicmp clean install site -s
~/.m2/c
[ +1 ]
Builds/tests ok, site looks good, reports look good (nits: no Jacoco report, no
japicmp, JIRA report missing some versions.)
Built using:
mvn clean install site -s ~/.m2/commons-settings.xml
On:
mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Use
[ +1 ]
LGTM: site looks good, javadoc ok, reports ok
Build using: mvn clean install site -s ~/.m2/commons-settings.xml
On: mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Azul Systems
[ +1 ]
Site looks good, javadoc ok, reports ok.
Built using: mvn clean install site -s ~/.m2/commons-settings.xml
On:
$Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime:
: "mac os x", version: "14.5", arch: "aarch64", family: "mac"
hbiestro@D3CC9YTYXF-Henri-Biestro commons-jexl-3.4.0-RC1 %
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.or
[ +1 ] LGTM
Site & Javadoc look good, changes & JIRA report clean (nice!), nit: Jacoco
report missing some classes
Built using:
mvn clean install site -Pjacoco -s ~/.m2/commons-settings.xml
On:
mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestr
[+1]
Site looks good, reports are clean (nit: coverage is low, JIRA report need some
work wrt fix version/reported version).
Build using:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Azul Syste
[ +1 ]
Site, Javadoc, reports look good.
Nit: site refers to version 1.7.0, so are the release notes and the JIRA report
is not helpful.
Using:
mvn clean install site
On:
mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.
[ +1 ]
Site looks good, javadoc looks good, reports Ok (nit jacoco missing).
Tested using:
mvn clean install site
On:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 17.0.8, vendor: Oracle Corporation, runtime:
/Libr
/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.4", arch: "aarch64", family: "mac"
hbiestro@D3CC9YTYXF-Henri-Biestro commons-io-2.16.0-RC1 %
Cheers
Henri
[ +1 ] build & tests ok;
- nits: site refers to 1.4.0, checkstyle warnings, no coverage report
Built with:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime:
/Library/Java
[ +1 ] Release
Build ok, tests ok, site looks good, report looks good (great coverage btw), a
japicmp report would be nice to have.
Built using:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-maven-3.8.6
Java version: 1.8.0_352, vendor: A
My bad, sorry. Next time I happen to break the build though, give me more than
3 minutes before you jump the gun! :-)
More seriously, I *always* check the actions after a commit and never let it in
failure state more than necessary for a fix. And you can always ping me on
Slack if you're worried
va version: 1.8.0_352, vendor: Azul Systems, Inc., runtime:
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.2.1", arch: "aarch64", family: "mac"
On:
Darwin D3CC9YTYXF
[+1] Release
Running;
mvn clean install site -s "$HOME/.m2/commons-settings.xml"
Build, test, site, Javadoc ok. On reports, it seems checkstyle is reporting
odd/wrong warnings.
Using:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/hbiestro/Java/apache-mave
[ +1 ]
Built locally using: mvn -s "$HOME/.m2/commons-settings.xml" -P jacoco -P
japicmp clean package site
On: Darwin henrib-MBP16 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct 9
21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 arm64
With: OpenJDK Runtime Environment (Zulu 8.66.0.15
[ +1 ]
Built using: mvn -s "$HOME/.m2/commons-settings.xml" -P jacoco -P japicmp
clean package site
On: Darwin henrib-MBP16 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct 9
21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 arm64
With: OpenJDK Runtime Environment (Zulu 8.66.0.15-CA-mac
Good to know, thanks for pointing this out.
Reduced flags public exposure in JEXL per last commit.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Your are correct, the engine (and the parser) do use its own JexlFeatures
copies (expressionFeatures/scriptFeatures members) that are never modified
after creation. An equivalent rule applies for JexlOptions btw, copied for
isolation for each evaluation. Those classes, by themselves, even if t
JexlPermissions concrete classes are but since this is an interface, anyone
could create a non-thread safe instance and use it. The same way a JexlFeatures
could be corrupted by being constructed with a non-thread safe namespace
predicate (making side-effects etc).
And for JexlFeatures, using
Builds ok, tests ok, site ok: [+1]
Nitpick: no coverage report in site (using mvn site), Spotbugs report a tad
verbose
hbiestro@hbiestro-MBP16 commons-net-3.10.0-RC1 % uname -a
Darwin hbiestro-MBP16 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:28
PDT 2023; root:xnu-8796.141.3.700.8~1/R
[+1]
Build and tests ok.
Small things that could be addressed in the future; test coverage and
check-style reports would be nice. Release notes could use some love, some old
JIRA should be assigned a 'fixed version' so as not to appear in front.
Tested using jdk8:
uname -a && mvn -version
D
Vote [ +1 ]
Site builds correctly (jdk8), reports are ok.
Tidbits: some Checkstyle and Javadoc (jdk17) errors could be addressed
Check build using:
mvn -s "$HOME/.m2/commons-settings.xml"
With:
Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /Users/hbiestro/Java/apach
My [+1] vote.
After a long trial & error process, got it to compile and test thanks Gary for
the patience and help);
Tidbits on the release, a few warnings could be quiesced and the release notes
seem short.
Tested using:
mvn -s "$HOME/.m2/commons-settings.xml" -V clean package site
with:
Some tests fail on a Mac (
Darwin hbiestro-MBP16 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:20
PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64) wether I try and run
with jdk8 or jdk17.
OpenJDK Runtime Environment (Zulu 8.66.0.15-CA-macos-aarch64) (build
1.8.0_352-b08) or (
[ +1] Release these artifacts
Built on:
22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:20 PDT 2023;
root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64
With:
openjdk version "1.8.0_352"
OpenJDK Runtime Environment (Zulu 8.66.0.15-CA-macos-aarch64) (build
1.8.0_352-b08)
OpenJDK 64-Bit Serve
Ho:
You should look at using JexlPermission which are probably easier and more
powerful than the JexlSandbox to enforce application security.
For loops, since there is no obvious guaranteed way to ensure they finish, the
possible route is to let scripts run in threads and cancel them if they run
ea. (As in: how do I integrate my own classes/packages?
-or- how do I ensure scripts are readonly and don't modify data?).
On 2023/08/07 10:08:59 Gary Gregory wrote:
> Do we need better documentation on the site?
>
> Gary
>
> On Mon, Aug 7, 2023, 5:45 AM Henri Biestro wrote
Hi;
JEXL 3.3. has increased default security by restricting permissions to a very
narrow set of allowed classes. In your case, you need to allow JEXL to
introspect your package by configuring your permissions. Have a look at
JexlPermissions javadoc for more explanations.
On JEXL 3.3, with Java 1
Hello Andres;
Interesting idea. A PR using Moditect conditioned on jdk profile (so we can
continue targeting java 8 without module info?) could be a first step to gauge
feasibility.
Cheers,
Henrib
-
To unsubscribe, e-mail: dev-u
Done. :-)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Merged it.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi;
Default permissions have changed with JEXL 3.3 to help with application
security.
I created the PR that restores the tests (
https://github.com/apache/commons-scxml/pull/123 ).
Henri
-
To unsubscribe, e-mail: dev-unsubscr...
+1
Checked src & bin signatures, site reports.
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /Users/henri.biestro/Java/apache-maven-3.8.1
Java version: 1.8.0_345, vendor: Azul Systems, Inc., runtime:
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
Def
/proper/commons-jexl/
Changes: https://commons.apache.org/proper/commons-jexl/changes-report.html
Download it from:
https://commons.apache.org/proper/commons-jexl/download_jexl.cgi
Henri Biestro,
for the Apache Commons JEXL team
This VOTE passes with the following binding +1 votes:
- Bruno Kinoshita
- Gary Gregory
- Henri Biestro
Thanks Bruno :-)
JEXL still needs another vote.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
+1
Build from tag using:
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/henri/Java/apache-maven-3.8.6
Java version: 1.8.0_362, vendor: Azul Systems, Inc., runtime:
/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform en
te and vote.
This vote will close no sooner than 72 hours from now.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Henri Biestro,
Release Manager (using key 4E066E0459CD109B)
For following is inte
Late tests reopened JEXL-393 and discovered a regression (JEXL-394).
RC2 will be proposed momentarily.
Sorry.
Unfortunately, more testing revealed a regression and a bug.
RC1 fails, RC2 will be proposed momentarily.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
t.
>
> Gary
>
>
> On Mon, Mar 13, 2023, 13:01 Henri Biestro (Apache)
> wrote:
>
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons JEXL 3.2.1 was released, so I would like to release
> > Apache Commo
+0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Henri Biestro,
Release Manager (using key 4E066E0459CD109B)
For following is intended as a helper and refresher for reviewers.
Validating a release candidate
==
These
Dear all;
I intend on starting the release of JEXL 3.3 with a landing (ideally) in
early March..
If you've any feedback on features, bugs, etc, that may impact that
release, please reach out now.
Cheers
> You have to consider the software in the context it is intended to be
> used.
Thank you for clarifying and illustrating those notions. We are in agreement
about JEXL intended usage and where the responsibility lies wrt security
choices.
But even in its usage context, with authenticated u
Let's restrict this discussion to the case of 'authenticated and authorised
users' of an 'enterprise platform'.
When we talk about 'unsafe input' vs 'safe input', I'm still confused about
what this actually entails. Let's assume we want those users to enter a (JEXL)
expression to express their
Fair points, thank you. They seem to lead into the point of view that JEXL (or
any scripting solution?) should not expose any feature that could be considered
security-related avoiding the CVE potential turmoils alltogether. Trusted
sanitised input is expected and required so this is a moot d
Hello Commons;
JEXL-381 is an attempt at making JEXL's default more secure or at least
less 'permeable' wrt to the application/platform/JVM/file-system/host that
runs it. Based on JexlPermissions - a crude security visibility manager -,
this restricts the *default* behavior of what is visible to J
[x] +1 Release these artifacts
Built from tag using:
mvn -V clean test install site
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /Users/henri.biestro/Java/apache-maven-3.6.1
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
Hi Stefan;
You actually don't change the main site, just the component site if I'm not
mistaken. I guess you found this;
http://commons.apache.org/site-publish.html#Main_site .
When everything is set correctly, the site-deploy target does everything for
you, namely push the site to its svn rep
>
> > On a Mac that used LDAP, user ids and groups are 'long':
> > henri.biestro@L-HBIESTRO-1 commons-compress % id
> > uid=1447288081(henri.biestro) gid=1024222515
>
> Didn't know that.
>
Neither did I!
>
> Are there any tests that actually use the uid/gid of the current user?
> Compress
Side note whilst trying to validate RC1:
On a Mac that used LDAP, user ids and groups are 'long':
henri.biestro@L-HBIESTRO-1 commons-compress % id
uid=1447288081(henri.biestro) gid=1024222515
A lot of tar tests will fail in this (probably rare) situation since tar
entries treat uid/gid need the
Checked with:
henri.biestro@L-HBIESTRO commons-io % mvn -V clean install site
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /Users/henri.biestro/Java/apache-maven-3.6.1
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
/Library/Ja
The following people voted on release Apache Commons JEXL 3.2.1:
Rob Tompkins +1
Bruno P. Kinoshita +1
Gary Gregory +1
Henri Biestro +1
Thanks!
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
japicmp, will do.
Thanks
On 2021/06/23 23:05:27, Rob Tompkins wrote:
> +1 builds and tests with 8 and 11
>
> signatures good
>
> reports all look reasonable
>
> (nit -> can we get japicmp implemented here?)
>
-
To unsubs
Early pre-check looks fine on site and reports.
Cheers
On 2021/06/23 02:10:16, Gary Gregory wrote:
> Hi All,
>
> FYI, I plan on cutting a release candidate soon.
>
> Gary
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons
time to look at it. Do we have any
(other) way to react to critical bugs besides releasing a 'service pack'
version ?
My hopeful +1
Cheers
On 2021/06/18 10:48:37, Henri Biestro wrote:
>
> We have fixed 2 critical bugs and 1 enhancement since Apache Commons JEXL 3.2
> was r
mons/KEYS
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you,
Henri Biestro,
Release Manager (using k
Thank you! Glad to be back.
On 2021/06/13 15:44:22, Matt Sicker wrote:
> Welcome back, Henri! Glad to see you again!
>
> On Sun, Jun 13, 2021 at 08:52 Gary Gregory wrote:
>
> > Let's welcome back Henri Biestro t
os x", version: "10.16", arch: "x86_64", family: "mac"
On 2021/06/13 11:31:28, Gary Gregory wrote:
> Yeah, coincidentally, I had to delete my Maven cache this week to fix an
> unrelated corrupted file and nuking the whole thing was simplest.
>
> Gary
&
at machine,
probably something funky on my end (corrupted .m2?).
Henrib
On 2021/06/12 18:28:52, Gary Gregory wrote:
> The parent POM version should be 52. Are you sure you are seing 51?
>
> Gary
>
>
> On Sat, Jun 12, 2021, 06:09 Henri Biestro wrote:
>
> > Using: mvn -
Using: mvn -V clean install site
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /Users/henri.biestro/Java/apache-maven-3.6.1
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Conte
I've been fumbling a bit with the release process, especially the site part,
I'm pretty sure I've missed a (few) steps somewhere since the site still refers
to release 3.1 or to 3.2.1-snapshot here and there.
I'm a bit lost about what the 'site' is :-) Is it the whole commons site or
only the
The following people voted on release JEXL 3.2:
Gary +1
Matt +1
Henrib +1
Gary, Matt, thank you!
On 2021/06/03 18:34:40, Henri Biestro wrote:
>
> We have fixed quite a few bugs and added some significant enhancements since
> Apache Commons JEXL 3.1 was released, so I would like t
te/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.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release becau
Found the culprit; it seems 'site' plugin uses the report section to generate
the javadoc whilst 'release' plugin uses the build section to do the same.
Fixed the issue by adding the same javadoc plugin configuration in build
section of the pom.xml.
On 2021/01/05 17:
d when writing code, validating code and also compiling code.
> 3 i think is also used when running unit tests
>
> Not sure if that will show other issues of fix this issue, hopefully
> it maybe highlight if different jvm's are being used when comparing
> inside and outside intel
none
..
I seek help, not diss.
On 2021/01/05 19:00:57, Gary Gregory wrote:
> You "should" fix the Javadoc warnings; -) or disable doclint.
>
> Gary
>
>
> On Tue, Jan 5, 2021, 12:06 Henri Biestro wrote:
>
> > Hello Te
Hello Team; Happy new year!
I'm trying (again) to release JEXL 3.2 and I'm stuck at the 'Maven release
plugin' step in https://commons.apache.org/releases/prepare.html.
Despite the fact a 'maven site' from IntelliJ does succeed, a 'mv
release:prepare -DtryRun' fails generating the Javadoc with
I still don't get why I need to (re)configure so many plugins in JEXL's pom -
any explanation is still welcome - but I managed to switch to Jacoco and
Spotbugs. Fighting with maven is always a tad tedious and I still fear trying
to release... Migrating to Java 8 code can now resume.
A recent commit in the code line (no pr btw) broke JEXL site's generation
ability since Cobertura does not support Java 8 lambda constructs. I've thus
been trying to switch to Jacoco as the coverage tool.
I've removed the cobertura.profile, added the jacoco.profile in the conf dir,
removed all C
1 - 100 of 109 matches
Mail list logo
