Dear all,
After a pretty long cycle, JEXL 2.1 is ready for review.
Here is a quick list of new features (from the release notes):
What's new in 2.1:
==
* A more thorough arithmetic (JexlArithmetic) that allows fine control over
decimals (scale and precision), a
new syntax for
Gary and Sebb pointed out that, per apache release rules, incompatible binaries
require new package name (i.e. jexl3).
My bad, sorry.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
Dear all,
JEXL 3.0 is ready for review.
The 2.1 attempt comments have been folded in; JEXL 3 being binary and source
code incompatible with JEXL 2, the code has moved to the new o.a.c.jexl3
package.
I've also moved some classes to the internal packages to make the public API
clearer for the
I'm obviously unfit as RM.
Sorry for the mess, feel free to remove any offending tag/branch/code.
Regards.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
Lists and Issue Tracking links here:
http://commons.apache.org/jexl/project-info.html
Henri Biestro
- On behalf of the Apache Commons community
Just a nitpick for release-manager wannabes like myself about the pom.xml
*releaseManagerKey*.
Since my gpg knowledge was a bit rusty, I suppose others might have to seek the
info too...
Anyhow, around the 'update KEYS file if necessary', may be we could add:
If you haven't done so, execute
Made me search a while; not a git project, seems to be done through
https://cms.apache.org/commons/ .
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
I’ll happily PR but which git project contains this file?
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
You are right, thanks for the catch.
Might be more useful to mention how to import your Apache public and private
key instead.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
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
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.
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
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 intellij.
>
> John
>
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:05:32, Henri Biestro
..
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 Team; Happy new year!
>
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
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:
,
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 -V clean in
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
&
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 to the
EYS
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 key 4E06
the 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 released, s
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:
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
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
ort.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 because...
Tha
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
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:
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
>
> > 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
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
[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:
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]
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
[ +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
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:
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:
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;
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
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
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
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
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
> 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
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
Late tests reopened JEXL-393 and discovered a regression (JEXL-394).
RC2 will be proposed momentarily.
Sorry.
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
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 Co
+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
Done. :-)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
/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
+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
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:
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:
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;
>
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
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
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
[ +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:
[ +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
[ +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
[+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:
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
/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-Biestr
[ +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:
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
e.
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 intended a
...
[ ] -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 guideline
This VOTE passes with the following binding +1 votes:
- Bruno Kinoshita
- Gary Gregory
- Henri Biestro
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
71 matches
Mail list logo
