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.
Emmanuel Bourg
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?
Emmanuel Bourg
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: dev
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: dev-h
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-mail
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 if you
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 ;-) )
Geronimo
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 TEXT
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 Bourg
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-unsubscr
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
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 Commons rules and
constrain
no 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: dev
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
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
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
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 wi
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
anged 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
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
natively 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-mail: dev-unsubscr...@common
wed 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-unsubscr...@commons.apache.org
For additional comma
ld 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-only tags, so let's not overload our
process
ny 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
ub:
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-mail: dev-unsub
t name (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-mail:
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.
Emmanuel Bo
ldn'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 additional commands, e
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 edito
to 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.
Emmanuel Bo
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.
Emmanuel
t 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.0-RC1 and
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
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.
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
ked 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.isJavaVe
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.org
eir 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
-
To
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
Emman
oposal:
1. Refactor Commons Math as a multi-module project, bump to version 5
2. Create two modules: geometry and legacy
3. Release Commons Math 5, without the legacy module
4. Spin-off new modules from the legacy module when needed
And I'm willing to help at least for the steps 1 and 2.
Emm
't be automated with tools, that's why I referred to the
multi-modules solution as "lightweight" compared to multiple components.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 1/09/2017 à 04:54, Dave Brosius a écrit :
> So volunteers? Gary, Emmanuel, others?? are you up to doing this?
I can setup the initial branch, but I need at least Gilles' consent and
an indication about the first modules he'd like to integrate.
Emmanuel Bo
g more modules after each release from the old CM
branch. That's equivalent to the creation of multiple components (you
cherry-pick the code that you want, and release it when ready), and you
keep the lightweight management of a single c
Le 27/08/2017 à 12:10, Bruno P. Kinoshita a écrit :
> [X] +1 Release it.
Emmanuel Bourg
signature.asc
Description: OpenPGP digital signature
ing more components.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
omponents.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 27/06/2017 à 00:02, Simon Spero a écrit :
> JDK 9 cannot generate or parse class files compiled with -target 1.5 [1].
AFAIK Java 9 can still parse 1.5 (and lower) class files.
Emmanuel Bourg
-
To unsubscribe, e-mail:
lusion of palindrome functions in [text] instead? If we
try to include whatever text processing function we can imagine in
[text], even if they aren't used, we'll end up with an oversized and
bloated API. I think the development should be driven by actual needs
and not by hypothetical usage.
Emmanuel
Checking palindromes
looks more like an academic exercise to me than a useful feature of a
text oriented library.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-ma
Le 19/06/2017 à 15:41, Stefan Bodewig a écrit :
> those two should go to the same list even if its "issues"?
Yes, sorry for the ambiguity.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commo
Le 19/06/2017 à 12:32, Stefan Bodewig a écrit :
> IMHO neither should go to dev@ and using notifications@ seems more
> logical to me. I'm going to change this for Compress and would likt to
> ask other components to check their settings as well so we can raise the
> signal ratio for dev@ again.
Le 11/06/2017 à 21:16, Gary Gregory a écrit :
> Can you show us a real problem that this would have solved?
+1, I don't understand what actual issue it would solve with
commons-compress.
Emmanuel Bourg
-
To unsubscribe, e-m
see what real issue it solves
with commons-compress. What incompatibility in commons-compress caused
an issue with an OSGi application? And was there no other alternative to
solve this issue?
Emmanuel Bourg
-
To unsubscribe, e-
bar 2.3.4)? That sounds like a nightmare. What is
the real gain? What existing problem would that solve exactly?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: de
ompiler.
+1 for using 1.6 as the baseline, but I don't see the need to publish
new releases with that target if nothing else changed.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
Le 25/04/2017 à 21:20, sebb a écrit :
> Problem is that the short form does not generate the correct relative
> links from component pages to the Commons parent site.
> Such links need an extra ../ segment.
Where are these links generated? We should switch them to absolute URLs.
Emman
an implementation of the
> JSTL Expression Language with extensions.
> -http://commons.apache.org/jexl/
> +http://commons.apache.org/proper/commons-jexl/
I'd prefer keeping the short form. I still hope we'll be able to get rid
of these horribly long URLs and return to the ones we had
es to ensure there
> are no problems.
Seeing Commons Lang 2 in the list I realize we'll have to dust off the
old branches and publish new releases (lang 2.x, configuration 1.x, jexl
2.x, math 3.x, pool 1.x, etc).
Emmanuel Bourg
-
To
w name.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 21/04/2017 à 15:12, sebb a écrit :
> Agreed?
I don't mind, but IntelliJ will highlight the groupId and suggest to
remove it :)
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additio
out to be released, we could start with this one and use it as an
example for the other components.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 19/04/2017 à 18:00, Pascal Schumacher a écrit :
> What do you think?
I agree for LANG-1065, this case is covered by the Java 8 API. The
improvements suggested in the other issues could be designed to work
with the java.time API, maybe in a dedicated commons-time component.
Emmanuel Bo
screen, playing sounds, calling remote services, accessing off-heap
memory, etc).
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
be immutable and contain the URL of the remote service, but the
operations couldn't be called by multiple threads.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
ead safe because it operates on an external
resource that doesn't work concurrently.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 18/04/2017 à 15:42, Gilles a écrit :
> And that's why "do-ocracy" should really matter more than
> "opinion".
And how do you reach consensus if you aren't open to others opinions?
Doing and not listening is just a variant of dictatorship, that's not my
vision of an
No objection was raised, the vote therefore passes. I'll proceed with
the migration.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ere "opinions" to offer to RNG, but you
rushed and imposed your design. So be it, I gave up, I didn't have
enough free time to keep up and argue with you, and there are other
areas where I can be useful.
Emmanuel Bourg
-
Hi all,
Now that JEXL 3.1 is out I think it's a good time to move the repository
to Git. I'd like to start a vote by lazy consensus about the migration,
the vote will be considered as passed after 72 hours if nobody objects.
Thank you,
Emmanuel Bourg
signature.asc
Description: OpenPGP
The Apache Commons Team is pleased to announce the availability of:
Apache Commons JEXL 3.1
Apache Commons JEXL is a library intended to facilitate the
implementation of dynamic and scripting features in applications and
frameworks written in Java.
The release notes can be reviewed at:
On 04/07/2017 11:59 PM, Emmanuel Bourg wrote:
> JEXL is ready for a new release, please review the artifacts and cast
> your votes.
>
> Changes since 3.0:
>
> https://dist.apache.org/repos/dist/dev/commons/jexl/3.1_RC1/RELEASE-NOTES.txt
> http://people.apache.
e
vote will be a non-issue.
> How can you be so sure? The last releases did not elicit an awful lot
> of votes; and that is for components that do not raise objections about
> their mere existence.
Give it a try?
Emmanuel Bourg
-
short does not seem to help either in conveying correctly what I
> perceive as a need for PMC action...
Thanks!
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
1 - 100 of 1071 matches
Mail list logo
