Eliotte,
I hope all your concerns are addressed.
Please approve PR if so, and with that, assume you "lifted" your -1 :)
Thanks
T
On Wed, Apr 5, 2023 at 1:35 PM Guillaume Nodet wrote:
> I've raised a new PR to re-deprecate StringUtils and inline it's usages:
>
> https://github.com/apache/maven-
I've raised a new PR to re-deprecate StringUtils and inline it's usages:
https://github.com/apache/maven-resolver/pull/277
Le mer. 5 avr. 2023 à 13:30, Elliotte Rusty Harold a
écrit :
> That's still a halfway measure. And we shouldn't move the public
> StringUtils package without a deprecation
That's still a halfway measure. And we shouldn't move the public
StringUtils package without a deprecation cycle anyway. This is public
API that can be used in projects that are not part of this repo or the
Apache Maven project. So I propose:
1. Keep StringUtils in deprecated form for now, to be r
I agree with you regarding duplication, this really adds "yet another"
StringUtils to classpath.
OTOH, I do see a value to drop non trivial (by size) dependency for sparse
use.
How about this proposal:
given un-deprecated StringUtils is used ONLY in (and below)
package org.eclipse.aether.internal
I'm -1 on this release. I specifically disagree with the undeprecation
of maven-resolver-util/src/main/java/org/eclipse/aether/util/StringUtils.java
in https://github.com/apache/maven-resolver/pull/275
We need fewer duplicate StringUtils classes in random packages, not
more of them. If we don't wa
Howdy,
The Resolver 1.9.8 is done:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.8
If anyone has/knows/feels there is more to be done in 1.9.8, yell here
please.
Also, if anyone has free cycles, and this mail has no "more to be done"
response
Hi,
The vote has passed with the following result:
+1: Sylwester Lachiewicz, Sławomir Jaranowski, Hervé Boutemy
PMC quorum: reached
I will promote the source release zip file to Apache distribution area and
the artifacts to the central repo.
Hello,
I've been investigating why mvn install without clean doesn't work for my
project. I've traced it down to using Dagger, though I think most (all?)
code-generating annotation processors will be affected.
I've created a simple project that reproduces the problem:
https://github.com/marq
