Re: [apache/commons-configuration] Use relocated artifact directly (PR #445)

[Jochen Wiedmann]

Are we really using slf4j within Commons?

Jochen


On Sun, Jul 7, 2024 at 12:38 PM Piotrek Żygieło 
wrote:

> [INFO] -< org.apache.commons:commons-configuration2 
> >--
> [INFO] Building Apache Commons Configuration 2.11.1-SNAPSHOT
> [INFO]   from pom.xml
> [INFO] [ jar 
> ]-
> [WARNING] The artifact org.slf4j:slf4j-log4j12:jar:2.0.13 has been relocated 
> to org.slf4j:slf4j-reload4j:jar:2.0.13
>
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/commons-configuration/pull/445
> Commit Summary
>
>- 7c2458d
>
> 
>Use relocated artifact directly
>
> File Changes
>
> (1 file )
>
>- *M* pom.xml
>
> 
>(2)
>
> Patch Links:
>
>- https://github.com/apache/commons-configuration/pull/445.patch
>- https://github.com/apache/commons-configuration/pull/445.diff
>
> —
> Reply to this email directly, view it on GitHub
> , or unsubscribe
> 
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: 
>


-- 
The woman was born in a full-blown thunderstorm. She probably told it to be
quiet. It probably did. (Robert Jordan, Winter's heart)

Re: [apache/commons-configuration] Use relocated artifact directly (PR #445)

[Gilles Sadowski]

Le dim. 7 juil. 2024 à 13:06, Jochen Wiedmann
 a écrit :
>
> Are we really using slf4j within Commons?

In this particular case, the dependency is in the "test" scope.

Gilles

>> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[Gary Gregory]

I'm not sure what you're missing, it works here:
https://github.com/apache/commons-fileupload/blob/e1ae2a1f64dfde98879bbd11f539beb3ebb76770/commons-fileupload2-core/src/test/java/org/apache/commons/fileupload2/core/DiskFileItemSerializeTest.java#L101-L104

Gary

On Sat, Jul 6, 2024 at 3:28 PM sendi Tho  wrote:
>
> Thank you for looking. I may be not clear .. here is what I am trying to say.
>
>
>
> 1.) The 2.0.0.M2 is using commons-io 2.16.1, here is the api
>
> https://commons.apache.org/proper//commons-io/apidocs/org/apache/commons/io/build/AbstractStreamBuilder.html
>
> setPath not public
>
> 2.) 
> https://github.com/apache/commons-fileupload/blob/master/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java#L71
>
>  public static class Builder extends 
> AbstractStreamBuilder { ...}
>
> does not have setPath() so we api consumers don;t have access to this setter.
>
> 3.) The following call from documentation does not work, as setPath is not 
> available.
>
> DiskFileItemFactory factory = 
> DiskFileItemFactory.builder().setPath(path).setBufferSize(DEFAULT_THRESHOLD).get();
>
>
> 
>
> Sent: Saturday, July 06, 2024 at 2:31 PM
> From: "Gary Gregory" 
> To: "Commons Developers List" 
> Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile 
> setPath
> Those two methods are public. What am I missing?
>
> Gary
>
> On Sat, Jul 6, 2024, 11:09 AM sendi Tho  wrote:
>
> > the exact issue I think is
> >
> > DiskFileItemFactory.Builder does not expose the property setPath and
> > setBufferSize.
> >
> >
> > in this file line# 82, #83
> >
> > commons-fileupload/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java
> >
> >
> > TIA.
> >
> >
> >
> >
> >
> > Sent: Friday, July 05, 2024 at 11:31 PM
> > From: "sendi Tho" 
> > To: dev@commons.apache.org
> > Cc: "Commons Developers List" 
> > Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> > -DiskItemFile setPath
> > hi, thank you for reviewing this. I am just trying to set the path for
> > temporaty file location for upload
> >
> >
> > String path = new File(System.getProperty("java.io.tmpdir")).getPath();
> >
> > DiskFileItemFactory factory = DiskFileItemFactory.builder().get();
> > // sets temporary location to store files
> > factory.setPath(path); // does not have setter for path
> > factory.setRepository();// does not have setter for repo, it does have the
> > getter though
> >
> >
> > or I tried to see if Jakarta has setter available
> >
> > JakartaServletDiskFileUpload upload = new
> > JakartaServletDiskFileUpload(factory);
> > upload.setSizeMax(MEMORY_THRESHOLD);
> > upload.setSizeMax(MEMORY_THRESHOLD);
> > upload.setPath(path);// not there eiter
> >
> >
> >
> >
> > Sent: Friday, July 05, 2024 at 9:04 PM
> > From: "Gary Gregory" 
> > To: "Commons Developers List" 
> > Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> > -DiskItemFile setPath
> > Hello,
> >
> > Could you point out precisely in code what you are wanting to do with
> > DiskFileFactory?
> >
> > Gary
> >
> > On Fri, Jul 5, 2024 at 8:18 AM sendi Tho 
> > wrote:
> > >
> > > Greetings guys,
> > >
> > >
> > > I am trying to use the new "commons-fileupload2-jakarta-servlet6"
> > > 
> > > org.apache.commons
> > > commons-fileupload2-jakarta-servlet6
> > > 2.0.0-M2
> > > 
> > >
> > >
> > > looks like the M2 jar from maven and the code differs ( getting warning
> > like bycode and source code does not match).
> > >
> > > so currently this build does not allow DiskFileFactory api users to set
> > the repository path.. is this intentional ? how to set the path?
> > >
> > > the path seems to come from FileItemFactory, but as FileItemFactory is
> > abstract and DiskItemFactory delegates through its builder the path setter
> > is lost.
> > >
> > > also I could not find the 1.x prod build ( assuming we are on 2.x
> > version) of upload2 servlet6. the 2.x using the builder and change in api..
> > I just wanted to change the package name to jakarta and be done with this..
> > :)
> > >
> > > thanks in advance.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache

Re: [collections] Predicate vs PredicateUtils

[Gary Gregory]

We don't want to break binary compatibility within the 4.x release line.

Gary

On Mon, Jul 1, 2024, 12:26 PM Julian Reschke 
wrote:

> Hi there!
>
> We are (finally) in the process of converting a project to
> commons-collections4. Unfortunately, we have a few APIs that return
> commons-collections3's Predicates.
>
> CC4 deprecates the custom Predicate class (good!), and these just extend
> JDK Predicates
> (
> https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/Predicate.html
> ).
>
> However, PredicateUtils (for instance
>
> https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/PredicateUtils.html#anyPredicate(java.util.Collection)
> )
> still require use of commons-collections4 Predicates. Is this an
> oversight, or am I missing something here? Shouldn't these utilities
> work with JDK Predicates as well?
>
> Best regards, Julian
>
> PS: let me know if I should move this over to Jira.
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [collections] Predicate vs PredicateUtils

[sendi Tho]

 
you are correct. it was using some older transitive deps.. resolved.  thank you 
for your patience .
 

Sent: Sunday, July 07, 2024 at 11:12 AM
From: "Gary Gregory" 
To: julian.resc...@gmx.de.invalid
Cc: "Commons Developers List" 
Subject: Re: [collections] Predicate vs PredicateUtils
We don't want to break binary compatibility within the 4.x release line.

Gary

On Mon, Jul 1, 2024, 12:26 PM Julian Reschke 
wrote:

> Hi there!
>
> We are (finally) in the process of converting a project to
> commons-collections4. Unfortunately, we have a few APIs that return
> commons-collections3's Predicates.
>
> CC4 deprecates the custom Predicate class (good!), and these just extend
> JDK Predicates
> (
> https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/Predicate.html
> ).
>
> However, PredicateUtils (for instance
>
> https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/PredicateUtils.html#anyPredicate(java.util.Collection[https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/PredicateUtils.html#anyPredicate(java.util.Collection])
> )
> still require use of commons-collections4 Predicates. Is this an
> oversight, or am I missing something here? Shouldn't these utilities
> work with JDK Predicates as well?
>
> Best regards, Julian
>
> PS: let me know if I should move this over to Jira.
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org