Re: [Math] How to update the web site?
Le jeu. 7 mars 2024 à 15:20, Gary Gregory a écrit : > > Please see https://commons.apache.org/site-publish.html Thanks. Trying $ mvn scm-publish:publish-scm results in ---CUT--- [ERROR] Failed to execute goal org.apache.maven.plugins:maven-scm-publish-plugin:3.2.1:publish-scm (default-cli) on project commons-math4-parent: Failed to check-in files to SCM: The svn command failed. svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option [ERROR] svn: E215004: Commit failed (details follow): [ERROR] svn: E215004: No more credentials or we tried too many times. [ERROR] Authentication failed ---CUT--- [Appending "--force-interactive" does not help.] By the way, if this is the recommended way, should we remove the "site"-related statements in the components' specific POM files? Gilles > > On Thu, Mar 7, 2024, 9:10 AM Gilles Sadowski wrote: > > > Hi. > > > > In relation to > > https://issues.apache.org/jira/browse/MATH-1667 > > I'm trying to regenerate the (live) site of [Math], but > > I've lost track of the "right" way to do it in accordance > > with the latest contents of the POM file; there is a > > profile named "site-checkout" but running > > $ mvn -P site-checkout > > did not check out the web site's files (into directory > > "site-content") as I was, perhaps wrongly, expecting. > > > > Also, is it still OK to (force) update of the live site's > > files (at the risk of breaking). Or has a safer way be > > put in place? [Some time ago, there was a discussion > > about moving web sites to "git" repositories...] > > > > Best, > > Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
One comment about the collection comparison...
For any collection that actually implements List, equality should *include*
order, not attempt to ignore it, right? The contract of a list is that the
order is consistent, and two lists with the same items in different order,
should not be considered equal.
e.g for List:
Best case scenario - The lengths are different and you dont have to check
any equalities
Worst case scenario - every item is equal and you have to iterate both
lists completely
Remaining Cases - Item [i] is different and you dont have to check
anything past that
(For pretty much any collection I think the best case is the same)
For sets, maybe it could be optimized by creating a new collection and
removing items as you find them, so each step necessarily gets smaller? Not
sure about this though.
On Thu, Mar 7, 2024 at 8:55 AM Gary D. Gregory wrote:
> On 2024/03/07 06:58:30 Mark Struberg wrote:
> > The question to me is how we can make it more robust.
> > In a Collection (but actually also in most lists) the order in which you
> get the values (Iterator or get(i)) is not deterministic. It can be
> different in one list than in another - even if they contain the exact same
> items.
>
> Hm, so to iterate through Lists in parallel would work but not with Sets.
>
> >
> > Not yet sure how to work around this. We can probably try to sort it
> first, but then again, if they do not implement Comparable it won't help
> much. Or do a containsElement based on reflection as well - but that would
> be rather slow.
>
> This is one of those: If you want support for the feature, it'll work, but
> it'll be slow because there is no other way to do it (for now if ever).
>
> Gary
>
> >
> > Same with Maps. There is a good reason why the key at least should
> implement equals/hashCode. If this is not the case, then we are not able to
> implement this properly I fear.
> >
> > Any ideas?
> >
> > LieGrue,
> > strub
> >
> > > Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> > >
> > > Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> > >
> > > For the diff, I'd suggest you test and iterable over a Collection
> > > instead of a List.
> > >
> > > Then you'd need a separate test and traversal for Map instances.
> > >
> > > (Still no common super-interface in Java 21 for Collections and
> Maps...)
> > >
> > > Gary
> > >
> > > On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg
> wrote:
> > >>
> > >> Hi Gregory!
> > >>
> > >> I did try this out and figured that I didn't think it though. Maybe I
> need to go a few steps back and explain the problem:
> > >>
> > >> I have the following constellation
> > >>
> > >> public class SomeInnerDTO {int field..} // NOT implements equals!
> > >> public class TheOuterDTO{ List innerList;..}
> > >>
> > >> My problem is that reflectionEquals (which I use in a unit test)
> tries to introspect fields even in java.util.classes. And for getting the
> values of those classes it tries to call a setAccessible(true);
> > >> And obviously here it fails. There is a ticket already open [1] which
> sugggests to use trySetAccessible. But I fear that will still do nothing
> and you won't get access to those inner knowledge inside
> java.util.LinkedList etc.
> > >>
> > >> And using equals() on the List sadly won't help either, as the
> SomeInnerDTO would also get compared with equals(), but that will obviously
> use identity comparison only :(
> > >>
> > >>
> > >> What I did for now (running all tests with a few projects right now,
> but looks promising):
> > >>
> > >> diff --git
> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> > >> index ff5276b04..cf878da40 100644
> > >> ---
> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> > >> +++
> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> > >> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final
> Object lhs, final Object rhs) {
> > >> if (bypassReflectionClasses != null
> > >> && (bypassReflectionClasses.contains(lhsClass) ||
> bypassReflectionClasses.contains(rhsClass))) {
> > >> isEquals = lhs.equals(rhs);
> > >> +} else if (testClass.isAssignableFrom(List.class)) {
> > >> +List lList = (List) lhs;
> > >> +List rList = (List) rhs;
> > >> +if (lList.size() != rList.size()) {
> > >> +isEquals = false;
> > >> +return this;
> > >> +}
> > >> +for (int i = 0; i < lList.size(); i++) {
> > >> +reflectionAppend(lList.get(i), rList.get(i));
> > >> +}
> > >> } else {
> > >>
> > >> I'm rather sure this is still not enough and there are plenty other
> cases to consider. Like e.g. handling Maps etc.
> > >> But at least that's the direction I try to approach it right now. And
> of
Re: [Math] How to update the web site?
Please see https://commons.apache.org/site-publish.html Gary On Thu, Mar 7, 2024, 9:10 AM Gilles Sadowski wrote: > Hi. > > In relation to > https://issues.apache.org/jira/browse/MATH-1667 > I'm trying to regenerate the (live) site of [Math], but > I've lost track of the "right" way to do it in accordance > with the latest contents of the POM file; there is a > profile named "site-checkout" but running > $ mvn -P site-checkout > did not check out the web site's files (into directory > "site-content") as I was, perhaps wrongly, expecting. > > Also, is it still OK to (force) update of the live site's > files (at the risk of breaking). Or has a safer way be > put in place? [Some time ago, there was a discussion > about moving web sites to "git" repositories...] > > Best, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[Math] How to update the web site?
Hi. In relation to https://issues.apache.org/jira/browse/MATH-1667 I'm trying to regenerate the (live) site of [Math], but I've lost track of the "right" way to do it in accordance with the latest contents of the POM file; there is a profile named "site-checkout" but running $ mvn -P site-checkout did not check out the web site's files (into directory "site-content") as I was, perhaps wrongly, expecting. Also, is it still OK to (force) update of the live site's files (at the risk of breaking). Or has a safer way be put in place? [Some time ago, there was a discussion about moving web sites to "git" repositories...] Best, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
On 2024/03/07 06:58:30 Mark Struberg wrote:
> The question to me is how we can make it more robust.
> In a Collection (but actually also in most lists) the order in which you get
> the values (Iterator or get(i)) is not deterministic. It can be different in
> one list than in another - even if they contain the exact same items.
Hm, so to iterate through Lists in parallel would work but not with Sets.
>
> Not yet sure how to work around this. We can probably try to sort it first,
> but then again, if they do not implement Comparable it won't help much. Or do
> a containsElement based on reflection as well - but that would be rather slow.
This is one of those: If you want support for the feature, it'll work, but
it'll be slow because there is no other way to do it (for now if ever).
Gary
>
> Same with Maps. There is a good reason why the key at least should implement
> equals/hashCode. If this is not the case, then we are not able to implement
> this properly I fear.
>
> Any ideas?
>
> LieGrue,
> strub
>
> > Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> >
> > Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> >
> > For the diff, I'd suggest you test and iterable over a Collection
> > instead of a List.
> >
> > Then you'd need a separate test and traversal for Map instances.
> >
> > (Still no common super-interface in Java 21 for Collections and Maps...)
> >
> > Gary
> >
> > On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg
> > wrote:
> >>
> >> Hi Gregory!
> >>
> >> I did try this out and figured that I didn't think it though. Maybe I need
> >> to go a few steps back and explain the problem:
> >>
> >> I have the following constellation
> >>
> >> public class SomeInnerDTO {int field..} // NOT implements equals!
> >> public class TheOuterDTO{ List innerList;..}
> >>
> >> My problem is that reflectionEquals (which I use in a unit test) tries to
> >> introspect fields even in java.util.classes. And for getting the values of
> >> those classes it tries to call a setAccessible(true);
> >> And obviously here it fails. There is a ticket already open [1] which
> >> sugggests to use trySetAccessible. But I fear that will still do nothing
> >> and you won't get access to those inner knowledge inside
> >> java.util.LinkedList etc.
> >>
> >> And using equals() on the List sadly won't help either, as the
> >> SomeInnerDTO would also get compared with equals(), but that will
> >> obviously use identity comparison only :(
> >>
> >>
> >> What I did for now (running all tests with a few projects right now, but
> >> looks promising):
> >>
> >> diff --git
> >> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> index ff5276b04..cf878da40 100644
> >> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object
> >> lhs, final Object rhs) {
> >> if (bypassReflectionClasses != null
> >> && (bypassReflectionClasses.contains(lhsClass) ||
> >> bypassReflectionClasses.contains(rhsClass))) {
> >> isEquals = lhs.equals(rhs);
> >> +} else if (testClass.isAssignableFrom(List.class)) {
> >> +List lList = (List) lhs;
> >> +List rList = (List) rhs;
> >> +if (lList.size() != rList.size()) {
> >> +isEquals = false;
> >> +return this;
> >> +}
> >> +for (int i = 0; i < lList.size(); i++) {
> >> +reflectionAppend(lList.get(i), rList.get(i));
> >> +}
> >> } else {
> >>
> >> I'm rather sure this is still not enough and there are plenty other cases
> >> to consider. Like e.g. handling Maps etc.
> >> But at least that's the direction I try to approach it right now. And of
> >> course this new part should potentially also be enabled by a flag...
> >>
> >> Will keep you updated.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/LANG-1711
> >>
> >>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
> >>>
> >>> This sounds like a good idea to try. I would call the option something
> >>> else
> >>> though. We would not skip calling equals if it is defined right? How about
> >>> "useEqualsIfPresent".
> >>>
> >>> Gary
> >>>
> >>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
> >>> wrote:
> >>>
> Hi!
>
> I have a question about EqualsBuilder#reflectionEquals. From Java9
> onwards
> we get more and more nasty module problems. Mainly because the code tries
> to recurse into java.util.* classes as well.
> I know that I can use setBypassReflectionClasses for those. But wouldn't
> it be fine to have an additional switch to
Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming
Could one calculate the hashes for each entry, sort them, and then
generate the hash for the collection?
On Thu, 7 Mar 2024 at 06:59, Mark Struberg wrote:
>
> The question to me is how we can make it more robust.
> In a Collection (but actually also in most lists) the order in which you get
> the values (Iterator or get(i)) is not deterministic. It can be different in
> one list than in another - even if they contain the exact same items.
>
> Not yet sure how to work around this. We can probably try to sort it first,
> but then again, if they do not implement Comparable it won't help much. Or do
> a containsElement based on reflection as well - but that would be rather slow.
>
> Same with Maps. There is a good reason why the key at least should implement
> equals/hashCode. If this is not the case, then we are not able to implement
> this properly I fear.
>
> Any ideas?
>
> LieGrue,
> strub
>
> > Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> >
> > Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> >
> > For the diff, I'd suggest you test and iterable over a Collection
> > instead of a List.
> >
> > Then you'd need a separate test and traversal for Map instances.
> >
> > (Still no common super-interface in Java 21 for Collections and Maps...)
> >
> > Gary
> >
> > On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg
> > wrote:
> >>
> >> Hi Gregory!
> >>
> >> I did try this out and figured that I didn't think it though. Maybe I need
> >> to go a few steps back and explain the problem:
> >>
> >> I have the following constellation
> >>
> >> public class SomeInnerDTO {int field..} // NOT implements equals!
> >> public class TheOuterDTO{ List innerList;..}
> >>
> >> My problem is that reflectionEquals (which I use in a unit test) tries to
> >> introspect fields even in java.util.classes. And for getting the values of
> >> those classes it tries to call a setAccessible(true);
> >> And obviously here it fails. There is a ticket already open [1] which
> >> sugggests to use trySetAccessible. But I fear that will still do nothing
> >> and you won't get access to those inner knowledge inside
> >> java.util.LinkedList etc.
> >>
> >> And using equals() on the List sadly won't help either, as the
> >> SomeInnerDTO would also get compared with equals(), but that will
> >> obviously use identity comparison only :(
> >>
> >>
> >> What I did for now (running all tests with a few projects right now, but
> >> looks promising):
> >>
> >> diff --git
> >> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> index ff5276b04..cf878da40 100644
> >> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object
> >> lhs, final Object rhs) {
> >> if (bypassReflectionClasses != null
> >> && (bypassReflectionClasses.contains(lhsClass) ||
> >> bypassReflectionClasses.contains(rhsClass))) {
> >> isEquals = lhs.equals(rhs);
> >> +} else if (testClass.isAssignableFrom(List.class)) {
> >> +List lList = (List) lhs;
> >> +List rList = (List) rhs;
> >> +if (lList.size() != rList.size()) {
> >> +isEquals = false;
> >> +return this;
> >> +}
> >> +for (int i = 0; i < lList.size(); i++) {
> >> +reflectionAppend(lList.get(i), rList.get(i));
> >> +}
> >> } else {
> >>
> >> I'm rather sure this is still not enough and there are plenty other cases
> >> to consider. Like e.g. handling Maps etc.
> >> But at least that's the direction I try to approach it right now. And of
> >> course this new part should potentially also be enabled by a flag...
> >>
> >> Will keep you updated.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/LANG-1711
> >>
> >>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
> >>>
> >>> This sounds like a good idea to try. I would call the option something
> >>> else
> >>> though. We would not skip calling equals if it is defined right? How about
> >>> "useEqualsIfPresent".
> >>>
> >>> Gary
> >>>
> >>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg
> >>> wrote:
> >>>
> Hi!
>
> I have a question about EqualsBuilder#reflectionEquals. From Java9
> onwards
> we get more and more nasty module problems. Mainly because the code tries
> to recurse into java.util.* classes as well.
> I know that I can use setBypassReflectionClasses for those. But wouldn't
> it be fine to have an additional switch to 'skipOnCustomEquals' or
> similar?
>
> The idea is to only use reflection on classes which do not provide their
> own equals method. One
