anges).
Fine if there is an easy and safe way to update a dependency, but
should we thank a robot?
+1, otherwise we may also thank Git, IntelliJ and OpenJDK for every
release :)
Emmanuel Bourg
-
To unsubscribe, e-mai
on this futile debate.
I don't care that much about the syntax of the assertions, I was just
clearing some IDE warnings when I removed the lambdas. I don't mind if
Gary reverts the commit if he feels better that way, this has zero
impact on the users
Le 19/11/2024 à 19:12, Emmanuel Bourg a écrit :
I ran "mvn clean" and "mvn package" 20 times, ignoring the first 10 runs
to warm up the system caches, and noted the total build time reported by
Maven. The build machine is a 6 years old laptop (Core i6 7500U, 32GB
RAM)
Le 19/11/2024 à 18:10, Emmanuel Bourg a écrit :
If you can prove your claim by demonstrating that this readability
improvement degrades the build time of Commons Validator by more than
0.01% I'll happily revert it.
Since I was asked privately in undiplomatic terms to do it myself
ll happily revert it.
Emmanuel Bourg
[1] https://junit.org/junit5/docs/snapshot/user-guide/
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
I've built recently were done with Java
17.
"{@link String}" triggers a warning in my IDE.
If the warning goes away with Java 17 then we'll remove it when the
minimum JDK requirement for Commons Validator is upgraded.
Emmanuel Bourg
---
Le 17/11/2024 à 23:57, sebb a écrit :
It seems to me perfectly OK to question a commit regardless of when it happened.
I think Emmanuel is within his rights to question whether adding the
dependency was the right thing to do.
And I think I'm not the only one surprised by the new dependencies.
challenged by a
vote if controversial.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
as a community,
to find a way to make decisions collectively.
So, would you accept a vote on this topic?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ighly appreciate your dedication to maintain the Apache Commons
projects, but you've made an error here. It happens, that's not a big
deal, but please listen to the community.
Would you accept to resolve this with a vote?
Emmanuel Bourg
[1] https://issues.apache.org/jira/brow
had in mind for the modularization of Commons
Compress.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
the active maintenance. I don't claim ownership
on the code but I still hope my merit hasn't evaporated too much and I
can still be trusted to make the right decisions on the classes I
contributed (i.e. remove commons-codec from the plist configuration
ethod gets widely used).
Emmanuel Bourg
[1]
https://github.com/apache/commons-compress/blob/863be804/src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java#L224
-
To unsubscribe, e-mail: dev-uns
Le 01/11/2024 à 21:12, Richard Zowalla a écrit :
IMHO (from a consumer pov) the addition of >1mb of dependencies is unfortunate.
commons-codec 1.17.1354KB
commons-lang 3.17.0658KB
commons-io2.17.0504KB
Total: 1.5MB :(
Emmanuel Bo
ng them.
Expanding the API call is necessary to remove the undesired dependency
on Commons IO.
Emmanuel Bourg
[1] https://github.com/apache/commons-compress/commit/bbe6fd9a
[2] https://github.com/apache/commons-compress/commit/aa71cb93
[3] https://github.com/apache/commons-comp
ncerned about the extra dependency on Commons Codec and
Commons IO, also added this year. I'd like to return to the state of
Commons Compress 1.25 with *zero* runtime dependency (besides the
optional ones required for the various compression algorithms
supported). For Codec and IO I suggest shad
rs is if the method can be inlined (static,
final or private method with a size under the configured threshold) and
the number of calls to the method.
Emmanuel Bourg
[1] https://www.baeldung.com/jvm-method-inlining
-
To uns
mpiler resolves the
static method call depending on the type of the instance, and the
bytecode generated has an invokestatic instruction pointing directly to
the right method, unlike invokevirtual instructions. There is no runtime
impact.
Hi Gary,
Le 28/10/2024 à 23:02, Gary Gregory a écrit :
Would you please explain why you need this change?
TY,
Gary
static methods are not inherited and can't be overridden in a subclass.
The 'final' modifier on a static method has no effect and can be removed.
within 2 or 3 years? I don't think so. I'm
not opposed to the idea but it would be weird in my opinion. I'd rather
shade the commons-codec Hex class.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
he dependency was the obvious choice to me
and in the spirit of the previous dependency removals.
Emmanuel Bourg
[1]
https://github.com/apache/commons-configuration/commit/02f66818#diff-a8d5e2a5cbeb500e59aca88e0613283c57d530c6df7630555d5a08bc5c3a660fR258
[2] https://github.com/apache/commons-co
opy of the Commons Codec class to avoid
the extra dependency.
Ironically, I authored the PList configurations 19 years ago, I hope I
can still have a say on how they are implemented today :)
Emmanuel Bourg
-
To unsubscribe, e
ly
complex JDK equivalent exists. And there is also the possibility of
shading a few classes or methods from another component at build time to
avoid pulling the full dependency at runtime.
Emmanuel Bourg
-
To
convenience outweighs the
maintainer's convenience. commons-lang3 doesn't bring enough value in
this case to justify its addition to the runtime dependencies.
Emmanuel Bourg
[1] https://github.com/apache/commons-compress/commit/87e898fa
-
g twice in
Pack200UnpackerAdapter?
Field field = FilterInputStream.class.getDeclaredField("in");
field.setAccessible(true);
return (InputStream) field.get(filterInputStream);
Emmanuel Bourg
-
To unsubscribe,
+1 for Java 8 as well. Unless there is a compelling feature in Java 11+
that could make a difference for beanutils from a user point of view.
Emmanuel Bourg
Le 25/09/2024 à 21:45, Josh Fenlason a écrit :
While some might have some preferences on more recent Java versions, I haven't
see
component is at the Java 8-11 level, just
use JDK 11 to build the releases.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
hen.
Btw I've pushed the necessary changes to commons-parent to enable the
frames with JDK 11.
Emmanuel Bourg
[1] https://www.azul.com/fr/azul-support-roadmap/
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
So there is nothing I can do to convince you to install OpenJDK 11 to
improve the user experience? Having multiple JDKs installed isn't
uncommon though.
Emmanuel Bourg
Le 23/05/2024 à 20:47, Gary Gregory a écrit :
ATM, I am using Java 17 for everything, at work, at FOSS.
Gary
On Thu
What about building with JDK 11 and the -frame option then? That's the
best of both worlds.
Emmanuel Bourg
Le 23/05/2024 à 18:44, Gary Gregory a écrit :
I disagree, I think the search box is a great feature.
Gary
On Thu, May 23, 2024, 11:26 AM Emmanuel Bourg wrote:
-0
The javado
-0
The javadoc was built with Java 17 and is less usable than the javadoc
generated by Java 8. I recommend building the next release with Java 8
instead.
Emmanuel Bourg
Le 19/05/2024 à 16:55, Gary Gregory a écrit :
We have fixed a few bugs and added enhancements since Apache Commons
CLI
ing with JDK 11.
Emmanuel Bourg
[1] https://bugs.openjdk.org/browse/JDK-8215599
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
The search box is a nice addition, but it's only useful if you know what
you are looking for. It doesn't replace a plain list of classes that can
be explored at a glance.
Emmanuel Bourg
Le 18/05/2024 à 13:09, Gary Gregory a écrit :
Notice that the newer Javadocs has a fancy Search
is really tedious with the new layout.
I don't know if the latest JDKs still support the framed layout, if they
do it would be nice to trigger the build option necessary, otherwise I
think we should switch to an alternative doclet, or stick to older JDKs
for now.
What do you think?
Emm
actions) for non critical purposes. It would be better
to have such notifications for CVEs only.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
of time.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
highlight the differences between the Servlet API and
commons-fileupload on the website, and encourage using the standard API
if neither streaming nor upload progression is required.
Emmanuel Bourg
-
To unsubscribe, e-mail
does not provide a way to cleanup after processing the
uploaded files, i.e. the commons-fileupload Cleaner
Isn't the temp file cleaning automatically handled by the Servlet
container? The API user shouldn't have to care about that.
Emma
ed to. We do things because it makes sense technically, and it
doesn't look so in this case.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
, but servers supporting the Jakarta API are recent and have
the file upload feature integrated. I'd expect commons-fileupload to go
to dormant in the near future rather than adapted for the jakarta namespace.
What did I miss?
Emma
it on TomEE side IMHO.
Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use the
managed package from tomcat-jdbc? If so we can't simply drop this
package from DBCP.
Emmanuel Bourg
-
To unsubscribe, e-mail
;s comment
about TomEE no longer using the managed package made me wonder if we
really need to bother at all.
Are we trying to fix a theoretical issue or are there actual users of
these classes expecting a fix?
Emmanuel Bourg
--
by component if there is a good
technical reason to switch (and I don't think JPMS support is a good one).
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
ge is copied at build time to
org.apache.commons.dbcp2.managed.jakarta
with the javax imports replaced.
This solution is easier than maintaining two versions is parallel.
What do you think?
Emmanuel Bourg
-
To unsubscribe, e
itate migrations. So no removal of deprecated methods
before dbcp4.
Emmanuel Bourg
On 28/12/2022 19:22, Romain Manni-Bucau wrote:
Hi Emmanuel,
You have
https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
which is usable i
ion jar at build time and see
how it works.
Emmanuel Bourg
Le 28/12/2022 à 07:24, Richard Zowalla a écrit :
There is a Jakarta artifact available for Narayana: narayana-jta-jakarta
For the SPI: jboss-transaction-spi-jakarta
(because JBoss plays the namespace game with their app server ;-) )
temporarily to publish quickly a
Jakarta variant.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
I would rather keep the ArrayUtils.shuffle() methods not deprecated, and
mention RNG in the Javadoc for more advanced usages. Adding a 100KB
dependency just to shuffle an array isn't optimal.
Emmanuel Bourg
Le 06/12/2022 à 21:40, Gary Gregory a écrit :
I am ok with both LANG and
Le 08/10/2022 à 17:56, sebb a écrit :
I don't think we should be cluttering the changes file with irrelevant
and potentially confusing information.
+1, changes.xml should be for user visible changes only (API changes,
bug fixes, updated language level, etc).
Emmanuel
On 10/06/2022 22:16, Rob Spoor wrote:
Since reflection is used to create the instances, isn't it possible to
support both?
+1, we should support both
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-uns
complex object structures is out of its scope.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
cific component) to review/merge the PRs?
I'd would vote favorably for a modularized CM 4.0 release, but I still
think that the math related components would be best served in their own
TLP with a dedicated community free of the Apache Com
longer
need the sandbox, and I think we should discontinue this practice. The
machine learning library could as well start its life on GitHub, it
doesn't need Apache Commons.
Emmanuel Bourg
-
To unsubscribe, e-mail
t should go dormant.
+1
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
.
> However if there are enough Commons developers who are able and
> willing to support the component, I won't veto it.
-1, I agree with sebb.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
gt; years.
Let's just give it a try with compress and reevaluate in a couple of month ?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
+1 for moving these files elsewhere. The project root should just
contain the pom.xml, license, notice, readme and CI files.
Emmanuel Bourg
Le 09/03/2021 à 02:15, Melloware Inc a écrit :
> In commons beanutils we recommend using /src/conf for these type of files.
>
> Sent from
-1 for commons-ml for the same reasons.
What about commons-machine-learning or commons-math-learning? The latter
is as long as commons-configuration.
Emmanuel Bourg
Le 2021-02-10 03:27, Ralph Goers a écrit :
-1 on commons-ml as the name. My first thought is such a repo would
hold stuff
amespace,
> but that should be doable.
-1, we don't need more JSR305-like annotations in the Java ecosystem.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
lized project structure and build
process.
Emmanuel Bourg
Le 16/07/2020 à 23:30, Rob Tompkins a écrit :
> I think we might be coming towards time to make this move or at least
> accommodate for gradle builds in commons. Let’s look to the success the
> Spring Framework has had here wit
he --release 6
flag.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ome.
Excellent post, thank you Gary.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
but the package was changed from java.util.jar to
io.pack200.
It's still missing the native library to speed up unpacking.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
with Java 14 in the same CI
run?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ware of this rule.
Alternatively I'm considering adding an independent Apache-2.0 licensed
interface, and having the GPLed code provide an implementation, maybe
using a META-INF service mechanism.
Emmanuel Bourg
-
To unsubscribe, e-ma
I'm not sure Apache projects are allowed to depend on such
libraries, but that would be odd not to be able to use it since it's
exactly the same code that we used in the JDK.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-u
his is purely theoretical.
And should it happen anyway it's trivial to restore the original branch
from a developer repository.
>> * we want fewer steps to our release process, not more
>
> No, we want as few as possible, but no fewer.
It's possible to work without read
it's non standard (never seen that anywhere)
* it doesn't solve any actual issue
* we want fewer steps to our release process, not more
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
types.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 18/10/2019 à 12:46, Gilles Sadowski a écrit :
> Why not state it explicitly (and make it a formal requirement for
> a release)?
-1, it restricts our freedom for no real gain, we have enough
constraints already.
Emmanuel
Le 18/10/2019 à 11:10, Xeno Amess a écrit :
> Do commons follow semver?
No but we care about backward compatibility.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-m
Le 18/10/2019 à 10:52, sebb a écrit :
> As noted in the OP, the change was part of changing the package name.
If the visibility change triggered a regression I think it should be
reverted.
Emmanuel bourg
-
To unsubscribe
branch on GitHub:
https://github.com/apache/commons-dbcp/commits/DBCP_1_5_x_BRANCH
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 02/07/2019 à 01:59, Gary Gregory a écrit :
> What would you call the method?
I don't know, setPropertyDirectInternal? It's private anyway, the name
isn't important.
Emmanuel Bourg
-
To unsubscribe, e-
e (there is nothing specific to arrays in the
implementation, it just sets the value as is) the PR looks good.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-
Le 28/05/2019 à 13:46, Gary Gregory a écrit :
> Thoughts?
Maybe we could make a more ambitious 'Strings' class with methods taken
from StringUtils and refactored with a fluent API to avoid the
combinatorial explosion of StringUtils? Just a wild idea.
E
Couldn't we set the ACL on the /proper path to read-only instead? At
least it doesn't break the URLs pointing to the current path.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additio
Le 12/05/2019 à 14:25, Gary Gregory a écrit :
> +1 to removing email addresses from exception messages. We should do a pass
> over all of Commons.
+1, makes sense.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-un
Oops wrong list, sorry.
Le 01/08/2018 à 13:00, Emmanuel Bourg a écrit :
> Hi all,
>
> The LocalString*.properties files are ASCII encoded which renders the
> modification of the non-english messages rather inconvenient.
> Contributors either need a specialized resource editor
facilitate
the modifications and transform them with native2ascii at build time?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 13/06/2018 à 21:51, Gary Gregory a écrit :
> #Release SHA-1s
> commons-dbcp2-2.4.0-null-pom.asc=df3fbc3dc6460cba003b16f8eba13ed3ffd8beef
> commons-dbcp2-2.4.0-null-jar.asc=3352f1b1ab04452445709d19272449bc5238d735
Are these "null" files except
+1, I prefer linear commit histories too.
Emmanuel Bourg
Le 09/06/2018 à 10:53, Pascal Schumacher a écrit :
> Hello everybody,
>
> in my opinion it is a good practice to always use the "--rebase" option
> when using "git pull". This keeps the history free of
On 18/05/2018 17:30, Gary Gregory wrote:
> Thoughts?
I wouldn't bother. The checksum is just there to ensure the download
worked properly, and for this even md5 is fine.
The authenticity of the artifacts is ensured by the GPG signatures.
Emmanu
Le 20/04/2018 à 00:12, sebb a écrit :
> I suggest asking Infra whether they are both going to be supported longer
> term.
FWIW when I migrated JEXL I had no other choice than using Gitbox. I'm
not sure Infra still accepts new git-wip repositories.
Emm
#x27;t that break old references?
Which ones? This is a new repository, there is no reference to it yet.
The old references to SVN will keep working.
> What about history?
The history is fully preserved. I even resurrected tags that were
missing from SVN (2.
Le 04/02/2018 à 00:46, Gilles a écrit :
> Link returns:
> ---CUT---
> XML Parsing Error: junk after document element Location:
> https://gitbox.apache.org/repos/commons-jexl.git Line Number 33, Column 8:
>
> ---^
> ---CUT---
Oops it's https://gitbox.apache.org/repos/asf/commons-jexl.git
---
e the old CVS style tags
(COMMONS_JEXL_3_1) to a shorter form (3.1). The mail notifications don't
work yet and the GitHub isn't fully up to date (only the master branch).
These issues are being tracked by INFRA-15965.
Emmanuel Bourg
-
+1
Emmanuel Bourg
Le 02/02/2018 à 18:54, Mark Thomas a écrit :
> Hello all,
>
> I propose that we create a new component [commons-signing].
>
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec co
ven plugin, a Gradle plugin and also a command line tool.
Will the scope be limited to the Symantec signing service?
Emmanuel Bourg
[1] https://ebourg.github.io/jsign/
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
7.0 after 3.6 would look odd.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 11/02/2017 02:41 PM, Gary Gregory wrote:
> I propose that all releases we do use the three part version format like
> major.minor.maintenance, for example 1.1.0 for the next daemon.
Why not simply 1.1 as we usually do?
Emmanuel
ooked to the
compile phase.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 9/10/2017 à 18:32, Gary Gregory a écrit :
> Can you please update the Javadocs on the various methods that show Java
> versions with examples up to Java 9 to make it clear that the Java 9 use
> case is handled?
Good idea, I added some examples to the public methods.
Emman
Le 9/10/2017 à 22:15, Emmanuel Bourg a écrit :
> ...by maven-javadoc-plugin 2.10.4 which depends on commons-lang 2.5.
Actually it depends on commons-lang 2.4, not 2.5.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsub
Thank you for the trace. This error is actually triggered by
maven-javadoc-plugin 2.10.4 which depends on commons-lang 2.5. It should
be fixed in the version 3.0.0. maven-site-plugin 3.6 already uses
commons-lang3.
Emmanuel Bourg
.6 currently blows up on isJavaVersionAtLeast.
Interesting, what exception do you get with maven-site-plugin?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
Le 29/09/2017 à 10:08, Emmanuel Bourg a écrit :
> I'd like to prepare a new release of Commons Lang 2 that addresses the
> Java 9 compatibility. I have two items in mind for this update, the
> automatic module name in the manifest of course, but also the
> SystemUtils.isJ
ws an Exception. This would be a minimal update branched off the
latest 2.6 release.
Do you see anything else that should be addressed in this update?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.or
their creation in pom.xml ?)
Or maybe even safer: branch from the last release tag and just add the
manifest entry for the new release.
I wonder if we should do the same for commons-lang 2.x, it's still
commonly used.
Emmanuel Bourg
--
Le 24/09/2017 à 14:28, sebb a écrit :
> I would be inclined to leave it open.
> Might be useful to collect reports against the component, even if
> nothing is planned to be done with them at present.
+1
Emmanuel Bourg
---
1 - 100 of 1184 matches
Mail list logo