Fwd: Is there any reasons for there being 8 ArrayUtil#isEmpty functions?

[Xeno Amess]

-- Forwarded message -
发件人： Xeno Amess 
Date: 2019年6月4日周二 上午12:07
Subject: Re: Is there any reasons for there being 8 ArrayUtil#isEmpty
functions?
To: dev-subscr...@commons.apache.org 


and notice that there be only one getLength function in ArrayUtils.

public static int getLength(final Object array) {
if (array == null) {
return 0;
}
return Array.getLength(array);
}


Xu Jin  于2019年6月3日周一 下午11:50写道：

> // --
>
> */** * ***
>
> *Checks if an array of Objects is empty or {@code null}. * * @param **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final Object[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive longs is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final long[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive ints is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final int[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive shorts is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final short[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive chars is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final char[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive bytes is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final byte[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive doubles is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final double[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive floats is empty or {@code null}. * * @param 
> **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final float[] array) {
> return *getLength*(array) == 0;
> }
>
>
> */** * ***
>
> *Checks if an array of primitive booleans is empty or {@code null}. * * 
> @param **array  *
>
>
>
> *the array to test * @return {@code true} if the array is empty or {@code 
> null} * @since 2.1 */*public static boolean isEmpty(final boolean[] array) {
> return *getLength*(array) == 0;
> }
>
> I just don’t understand.
>
> Why we not using one single function like
>
>
>
> public static boolean isEmpty(Object array) {
> return *getLength*(array) == 0;
> }
>
>
>
> ?
>

Re: [lang] Giant StringUtils vs. NullSafeStrings.

[Xeno Amess]

Then 10 years later JDK has its own Strings, and users get confused then.

Emmanuel Bourg  于2019年6月4日周二 下午6:58写道：

> 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 Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Is there some plans for implementing some primitive datas tructures?

[Xeno Amess]

Recently I feel like sometimes ArrayList or HashSet is
just...too slow.
If we implement the datas tructures in primitive types and offer some
functions to fit the common interfaces, I really think that can help.
Sorry for my poor english, but you can get what I mean at
https://github.com/XenoAmess/commonx/tree/master/src/main/java/com/xenoamess/commons/collections/list/primitive_array_lists


*LongArrayList score : 12399758ArrayList score : 27851927*

According to the test result, sometimes it will run more than 1 times
faster when we use primitive such data structures...
I just wonder:
1.  Is this thing done by some libraries before?
2. Are there any guys who are as interested with such things as me? (as I
don't think I can fo this translation of codes completely by myself.)
3. If 1->false , then will there be any possibility that apache do such
things?(either clean room implementations or translation?)
Thx..
-XenoAmess.

Re: [lang] Giant StringUtils vs. NullSafeStrings.

[Xeno Amess]

As a fact that class jdk.internal.joptsimple.internal.Strings does
exist, I don't think we shall add a class named Strings.
That will be misleading sometimes.

Matt Sicker  于2019年6月5日周三 上午12:32写道：
>
> The JDK is the only source allowed to modify java.lang.String, so
> they'd likely add static methods to that directly like String.join()
> and the others. The plural name thing was more of an issue with an
> interface Thing and utility class Things. As of Java 8, there's
> typically no need to have a Things class because the Thing interface
> can have static methods on it. For example, see all the static methods
> added to Comparator that would have typically gone into a class named
> Comparators (like Collector/Collectors).
>
> On Tue, 4 Jun 2019 at 06:07, Xeno Amess  wrote:
> >
> > Then 10 years later JDK has its own Strings, and users get confused then.
> >
> > Emmanuel Bourg  于2019年6月4日周二 下午6:58写道：
> >
> > > 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 Bourg
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
>
>
> --
> Matt Sicker 
>
> -
> 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

Re: [lang] org.apache.commons.text.lookup.IllegalArgumentExceptions to [lang].

[Xeno Amess]

Why don't you use java.lang.IllegalArgumentException instead?
And, why we need such a class, but not using
java.lang.IllegalArgumentException there?

Gary Gregory  于2019年9月3日周二 下午11:18写道：
>
> Hi All:
>
> I propose we take
> https://commons.apache.org/proper/commons-text/xref/org/apache/commons/text/lookup/IllegalArgumentExceptions.html#IllegalArgumentExceptions
> and make it a public class in [lang]. FWIW, I use a class like this in many
> projects at work.
>
> Gary

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

Re: [lang] org.apache.commons.text.lookup.IllegalArgumentExceptions to [lang].

[Xeno Amess]

or me. This is straightforward:
> > >
> > > throw IllegalArgumentExceptions.format(e, "%s: %s %s operation %s: %s",
> > > source, method, pathSpec, operation.getOperationId(), e.toString());
> > >
> > > The following not as much:
> > >
> > > throw ExceptionUtils.format(IllegalArgumentException::new, e, "%s: %s %s
> > > operation %s: %s", source, method, pathSpec, operation.getOperationId(),
> > > e.toString());
> > >
> > > So it could be that IllegalArgumentExceptions.format() is implemented in
> > > terms of ExceptionUtils.format but there does not seem to be much to gain
> > > from that.
> > >
> > > Gary
> > >
> > >
> > >>
> > >> On 03/09/2019 19:04, Gary Gregory wrote:
> > >> > Please read the source.
> > >> >
> > >> > On Tue, Sep 3, 2019, 12:27 Xeno Amess  wrote:
> > >> >
> > >> >> Why don't you use java.lang.IllegalArgumentException instead?
> > >> >> And, why we need such a class, but not using
> > >> >> java.lang.IllegalArgumentException there?
> > >> >>
> > >> >> Gary Gregory  于2019年9月3日周二 下午11:18写道：
> > >> >>>
> > >> >>> Hi All:
> > >> >>>
> > >> >>> I propose we take
> > >> >>>
> > >> >>
> > >> https://commons.apache.org/proper/commons-text/xref/org/apache/commons/text/lookup/IllegalArgumentExceptions.html#IllegalArgumentExceptions
> > >> >>> and make it a public class in [lang]. FWIW, I use a class like this 
> > >> >>> in
> > >> >> many
> > >> >>> projects at work.
> > >> >>>
> > >> >>> Gary
>
> -
> 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

Re: [lang] org.apache.commons.text.lookup.IllegalArgumentExceptions to [lang].

[Xeno Amess]

Well, if you do think repeating the similar codes for 100+ times is
better than reflection and be more elegant or easier to read or
something, then you can try maintain them.
There is 100+ Throwable classes who have string constructor in JDK IMO.
And don't forget some of them might only be in some certain versions
of JDK, and be careful about making them compilable on other version
of JDKs.
Also you might try to use some preprocess way to generate such
classes, some ways like lombok do (although that might be
controversial).

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

Re: [LAZY][VOTE] Release Commons Parent version 49 from RC2

[Xeno Amess]

+0
As for 49 comming soon, I really think it a good time to consider
fixing https://github.com/apache/commons-parent/pull/5 and
https://github.com/apache/commons-lang/pull/428

Gary Gregory  于2019年9月15日周日 上午8:07写道：
>
> +1
>
> Builds OK from the git RC tag using Oracle Java 8:
>
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 2019-08-27T11:06:16-04:00)
> Maven home: C:\Java\apache-maven-3.6.2\bin\..
> Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_221\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Tested with Commons Collection's git master HEAD OK.
>
> Gary
>
> On Wed, Sep 11, 2019 at 9:22 PM Rob Tompkins  wrote:
>
> > We have fixed quite a few bugs and added some significant enhancements
> > since
> > Apache Commons Parent 48 was released, so I would like to release Apache
> > Commons
> > Parent 49.
> >
> > Apache Commons Parent 49 RC2 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2
> > (svn
> > revision 35767)
> >
> > The Git tag commons-parent-49-RC2 commit for this RC is
> > 379376be9a721deaa7bf4f13b5c4680787004524 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=379376be9a721deaa7bf4f13b5c4680787004524
> >
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> > --branch
> > commons-parent-49-RC2
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1468/org/apache/commons/commons-parent/49/
> >
> > These are the Maven artifacts:
> >
> > #Nexus SHA-1s
> > commons-parent-49-site.xml=29a5e6f8a0f8166e791483703a1baa982b21a8ae
> > commons-parent-49.pom=b9c55a15d726cb9ddb18c6de138b232fa95289e2
> >
> > #Release SHA-512s
> > #Wed Sep 11 18:07:15 PDT 2019
> >
> > commons-parent-49-src-zip=75a9dec81bb6d3c5d0b1889ef3ee022cbd4a9c36ca21e238f136e927da4f2486742445f798a60a69b11e47c2cf6fdaaf81acf499a07ad33f0256e111b0994ded
> >
> > commons-parent-49-pom=6ee38558cf5ea3893d7cecd4f569405c11cbc14837519139876adb5060351cb545e0f95f609e3358385d98794f5daa8e7bd9fc724d2e5e32da1b666bca1c57b8
> >
> > commons-parent-49-src-tar.gz=f5a03ff39f3f6b057965ba9759e96f32d51ea9a5e2bbf2831f7cb55b144674865c158e1aa283112f0d502407094887612cb24a270ff558a989cf82da5d9d03e3
> >
> > I have tested this with 'mvn clean install site' using:
> > Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> > 2019-08-27T08:06:16-07:00)
> > Maven home: /usr/local/Cellar/maven/3.6.2/libexec
> > Java version: 1.8.0_222, vendor: Amazon.com Inc., runtime:
> > /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
> >
> >
> > Details of changes since 48 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/site
> > (note some *relative* links are broken and the 49 directories are not
> > yet
> > created - these will be OK once the site is deployed.)
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/49-RC2/site/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 72 hours from now.
> >
> >   [ ] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > Thank you,
> >
> > Rob Tompkins,
> > Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> >
> > For following is intended as a helper and refresher for reviewers.
> >
> > Validating a release candidate
> > ==
> >
> > These guidelines are NOT complete.
> >
> > Requirements: Git, Java, Maven.
> >
> > You can validate a release from a release candidate (RC) tag as follows.
> >
> > 1) Clone and checkout the RC:
> >
> > git clone https://gitbox.apache.org/repos/asf/commons-parent.git -b
> > commons-parent-49-RC2
> > cd commons-parent-49-RC2
> >
> > 2) Check Apache licenses:
> >
> > mvn apache-rat:check
> >
> > 3) Build the package:
> >
> > mvn -V clean package
> >
> > You can record the Maven and Java version produced by -V in your VOTE
> > reply.
> >
> > 4) Build the site for a single module project:
> >
> > mvn site
> > Check the site reports in:
> > target\site\index.html
> >
> > 4) Build the site for a multi-module project:
> >
> > mvn site
> > mvn site:stage
> > Check the site reports in:
> > target\site\index.html
> > -

Re: [exec] Update from Java 5 to 6

[Xeno Amess]

+1 for java 8
I just assume developers who still using java 6 do not care about
upgrading their commons too...
But what is the meaning of jigsawI mean, everybody use maven and
maven is good, right?

sebb  于2019年10月10日周四 上午6:55写道：
>
> On Wed, 9 Oct 2019 at 22:38, John Patrick  wrote:
> >
> > Regarding the question, it was by Simon Ritter (Azul Systems
> > previously Oracle previously Sun). "Put your hand up if your running
> > applications in production using Java X", started with Java 8, then
> > asked about 11, then 12 and 13, then asked 7 and then 6. Not sure if
> > he said Java 5 but I don't think he did.
>
> OK, thanks.
>
> > It's great java is backwards compatible, but Java 5 was EOL 2009, Java
> > 6 was EOL 2013, Java 7 was EOL 2015, java 8 EOL 2019 personal usage
> > 2020 and AdoptOpenJDK 2023).
> >
> > People jokes and complained about Java was dead or slow and releases
> > took 2-5 years... JPMS has now been released for 2 years and how many
> > frameworks/applications have actually release a version where you can
> > take advantage of modules and create real lightweight images.
>
> Most of Commons components are quite small, so is this really a concern?
>
> > I've been using Java since 1.1, I was annoyed major releases took
> > ages, but I'm more annoyed about the whole java ecosystem not stepping
> > up as they have got use to the previously slow release cycles. I
> > realise OpenSource project is done in peoples spare time and they are
> > choosing to participate, but I've tried with multiple projects to
> > raise pull requests to help taking the next steps.
> >
> > My personal view is all commons projects should aim from Jan 2020 to
> > bump to creating multi release jars of Java 8 and Java 11, so people
> > using Java 8 are still supported and people using Java 11+ can uses
> > modules.
>
> And anyone using Java 7 or earlier is excluded.
>
> Unless I am mistaken, if we don't create these multi-release jars,
> people will still be able to use existing releases.
>
> >
> > On Wed, 9 Oct 2019 at 18:21, Alex Herbert  wrote:
> > >
> > > On 09/10/2019 14:12, Gary Gregory wrote:
> > > > Hi All,
> > > >
> > > > I'd like to update Commons Exec from Java 5 to 6 to get it to build on 
> > > > Java
> > > > 11.
> > > >
> > > > Gary
> > >
> > > Gary changed git master to update to 1.6 but travis was not able to
> > > build for older JDKs.
> > >
> > > I have tried following the recommended instructions for their trusty
> > > distribution to use JDK 6 [1]. This did not work [2]. It would appear
> > > that travis cannot support openjdk6 any more.
> > >
> > > Using 'dist: trusty' allows a clean build on JDK 7, 8, 11.
> > >
> > > I recommend dropping openjdk6 from the build matrix.
> > >
> > > Other items from the .travis.yml are the broken configuration for the
> > > coveralls report. This can be fixed separately as the pom needs some
> > > updating.
> > >
> > > Alex
> > >
> > > [1]
> > > https://docs.travis-ci.com/user/reference/trusty/#jvm-clojure-groovy-java-scala-images
> > >
> > > [2] https://travis-ci.org/apache/commons-exec/builds/595713743
> > >
> > >
> > > -
> > > 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.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java

[Xeno Amess]

Do commons follow semver?

Emmanuel Bourg  于 2019年10月18日周五 下午5:05写道：

> 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, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [lang] immutable BitSet

[Xeno Amess]

then it is better to make a AbstractBitSet abstract class?and two sub classes 
MutableBitSet and ImmutableBitSet...

?? Outlook for Android


From: Gary Gregory 
Sent: Tuesday, October 29, 2019 2:42:29 AM
To: Commons Developers List 
Subject: [lang] immutable BitSet

Hi All,

Any thoughts for or against adding an ImmutableBitSet as a subclass
of BitSet?

It would throw an exception on attempt to mutate.

I can then be used to define an EMPTY_BITSET constant.

I could also be used in some of our methods that return a new empty bit
set, if appropriate of course.

Gary

Re: [lang] immutable BitSet

[Xeno Amess]

Then all ImmutableBitSet instance are instance of a mutable BitSet class
when we use instance of.
I just worry that could be kind of misleading sometimes.


Gary Gregory  于 2019年10月29日周二 上午3:29写道：

> On Mon, Oct 28, 2019 at 3:16 PM Xeno Amess  wrote:
>
> > then it is better to make a AbstractBitSet abstract class?and two sub
> > classes MutableBitSet and ImmutableBitSet...
> >
>
> Why would you need that? The JRE already has a BitSet class. The idea is to
> reuse it, hence the new Lang immutable type extending the existing JRE
> mutable one. I do not think we need to reinvent the wheel here.
>
> Gary
>
>
> > ?? Outlook for Android<https://aka.ms/ghei36>
> >
> > 
> > From: Gary Gregory 
> > Sent: Tuesday, October 29, 2019 2:42:29 AM
> > To: Commons Developers List 
> > Subject: [lang] immutable BitSet
> >
> > Hi All,
> >
> > Any thoughts for or against adding an ImmutableBitSet as a subclass
> > of BitSet?
> >
> > It would throw an exception on attempt to mutate.
> >
> > I can then be used to define an EMPTY_BITSET constant.
> >
> > I could also be used in some of our methods that return a new empty bit
> > set, if appropriate of course.
> >
> > Gary
> >
>

some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

I'm trying to migrate to commons-vfs2 now
severial things I found not quite right / amazing.

1.
 I tested version 2.6.0 and 2.5.0, and I just start at
VSF.getManager() (of cause I have no additional contfigure or
something)

It said class not
found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider

And I looked into your binary jars I get from maven central (2.6.0).

they really do not have that class WebdavFileProvider.
(even not found that package org.apache.commons.vfs2.provider.webdav)

And after I downgrade to 2.3 (I really wonder why 2.3 not 2.3.0 but
that is not important)
It can run now.(and never tell me class not found again)
I dont't want to try 2.4.0. Really bad connection here(I'm in a villige now).
All I get is:
2.6.0, broken.
2.5.0, broken.
2.3, fine.

According to the file on github, it said it might be deprecated, so I
wonder if you already deprecate d it and you just forgotten it?

 btw, according to your webpage https://commons.apache.org/proper/commons-vfs/
there even do not exist 2.6.0
But there be a 2.6.0 in maven central.
really make me confused.

2.
for using commons-vfs2 I downgrade slf4j from 2.0.0alpha to 1.7.30
We all know slf4j's author really do not care about backward
maintenance or something.
His codes are never able to migrate.
even though, will there be some plan about using reflect or something
to make vfs2 CAN suit slf4j 2.0?

3.
for some reason I need to deal with relative file path.
Is there any guide about using relative file path in vfs2?

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

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

Right now I'm using something like
this to deal with relative files.
But I just think there might be a more elegant way...

fileSystemManager = new
org.apache.commons.vfs2.impl.StandardFileSystemManager();
fileSystemManager.setLogger(null);
try {
fileSystemManager.init();
fileSystemManager.setBaseFile(new File(""));
} catch (FileSystemException e) {
e.printStackTrace();
}

Xeno Amess  于2020年1月19日周日 下午6:08写道：
>
> I'm trying to migrate to commons-vfs2 now
> severial things I found not quite right / amazing.
>
> 1.
>  I tested version 2.6.0 and 2.5.0, and I just start at
> VSF.getManager() (of cause I have no additional contfigure or
> something)
>
> It said class not
> found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider
>
> And I looked into your binary jars I get from maven central (2.6.0).
>
> they really do not have that class WebdavFileProvider.
> (even not found that package org.apache.commons.vfs2.provider.webdav)
>
> And after I downgrade to 2.3 (I really wonder why 2.3 not 2.3.0 but
> that is not important)
> It can run now.(and never tell me class not found again)
> I dont't want to try 2.4.0. Really bad connection here(I'm in a villige now).
> All I get is:
> 2.6.0, broken.
> 2.5.0, broken.
> 2.3, fine.
>
> According to the file on github, it said it might be deprecated, so I
> wonder if you already deprecate d it and you just forgotten it?
>
>  btw, according to your webpage https://commons.apache.org/proper/commons-vfs/
> there even do not exist 2.6.0
> But there be a 2.6.0 in maven central.
> really make me confused.
>
> 2.
> for using commons-vfs2 I downgrade slf4j from 2.0.0alpha to 1.7.30
> We all know slf4j's author really do not care about backward
> maintenance or something.
> His codes are never able to migrate.
> even though, will there be some plan about using reflect or something
> to make vfs2 CAN suit slf4j 2.0?
>
> 3.
> for some reason I need to deal with relative file path.
> Is there any guide about using relative file path in vfs2?

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

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

The key point is even if I do not wanna use it I must have this
class,or VFS.getManager() can never run.

IMO this type of class relationship cause the project where hold this
class must be added into vfs's pom as a dependency, or just move class
VFS into that project aswell.

Otherwise we should not let the VFS.getManager() rely on this class.

Thanks for finding this class though.

btw I tested 2.4, 2.4 is correct.

Rob Spoor  于2020年1月19日周日 下午10:00写道：
>
> The class was there in release 2.4.1:
> https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.4.1/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/webdav/WebdavFileProvider.java.
> In the next release, 2.5.0, it can indeed no longer be found. A bit of
> investigating showed that the webdav classes got moved to a new
> artifact:
> https://github.com/apache/commons-vfs/commit/42ff473acbb5363b88f5ab3c5fddbae7b206c1d2
>
> That means you can still use it, you just need to include an extra
> dependency:
> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit1/2.6.0
>
> There's apparently also a Jackrabbit 2 version available:
> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit2/2.6.0
>
>
> On 19/01/2020 11:24, Xeno Amess wrote:
> > Right now I'm using something like
> > this to deal with relative files.
> > But I just think there might be a more elegant way...
> >
> > fileSystemManager = new
> > org.apache.commons.vfs2.impl.StandardFileSystemManager();
> > fileSystemManager.setLogger(null);
> > try {
> >  fileSystemManager.init();
> >  fileSystemManager.setBaseFile(new File(""));
> > } catch (FileSystemException e) {
> >  e.printStackTrace();
> > }
> >
> > Xeno Amess  于2020年1月19日周日 下午6:08写道：
> >>
> >> I'm trying to migrate to commons-vfs2 now
> >> severial things I found not quite right / amazing.
> >>
> >> 1.
> >>   I tested version 2.6.0 and 2.5.0, and I just start at
> >> VSF.getManager() (of cause I have no additional contfigure or
> >> something)
> >>
> >> It said class not
> >> found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider
> >>
> >> And I looked into your binary jars I get from maven central (2.6.0).
> >>
> >> they really do not have that class WebdavFileProvider.
> >> (even not found that package org.apache.commons.vfs2.provider.webdav)
> >>
> >> And after I downgrade to 2.3 (I really wonder why 2.3 not 2.3.0 but
> >> that is not important)
> >> It can run now.(and never tell me class not found again)
> >> I dont't want to try 2.4.0. Really bad connection here(I'm in a villige 
> >> now).
> >> All I get is:
> >> 2.6.0, broken.
> >> 2.5.0, broken.
> >> 2.3, fine.
> >>
> >> According to the file on github, it said it might be deprecated, so I
> >> wonder if you already deprecate d it and you just forgotten it?
> >>
> >>   btw, according to your webpage 
> >> https://commons.apache.org/proper/commons-vfs/
> >> there even do not exist 2.6.0
> >> But there be a 2.6.0 in maven central.
> >> really make me confused.
> >>
> >> 2.
> >> for using commons-vfs2 I downgrade slf4j from 2.0.0alpha to 1.7.30
> >> We all know slf4j's author really do not care about backward
> >> maintenance or something.
> >> His codes are never able to migrate.
> >> even though, will there be some plan about using reflect or something
> >> to make vfs2 CAN suit slf4j 2.0?
> >>
> >> 3.
> >> for some reason I need to deal with relative file path.
> >> Is there any guide about using relative file path in vfs2?
> >
> > -
> > 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

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

OK I get where is bugged.
I will fix it and add a test for that never happen again.

Xeno Amess  于2020年1月19日周日 下午11:21写道：
>
> The key point is even if I do not wanna use it I must have this
> class,or VFS.getManager() can never run.
>
> IMO this type of class relationship cause the project where hold this
> class must be added into vfs's pom as a dependency, or just move class
> VFS into that project aswell.
>
> Otherwise we should not let the VFS.getManager() rely on this class.
>
> Thanks for finding this class though.
>
> btw I tested 2.4, 2.4 is correct.
>
> Rob Spoor  于2020年1月19日周日 下午10:00写道：
> >
> > The class was there in release 2.4.1:
> > https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.4.1/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/webdav/WebdavFileProvider.java.
> > In the next release, 2.5.0, it can indeed no longer be found. A bit of
> > investigating showed that the webdav classes got moved to a new
> > artifact:
> > https://github.com/apache/commons-vfs/commit/42ff473acbb5363b88f5ab3c5fddbae7b206c1d2
> >
> > That means you can still use it, you just need to include an extra
> > dependency:
> > https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit1/2.6.0
> >
> > There's apparently also a Jackrabbit 2 version available:
> > https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit2/2.6.0
> >
> >
> > On 19/01/2020 11:24, Xeno Amess wrote:
> > > Right now I'm using something like
> > > this to deal with relative files.
> > > But I just think there might be a more elegant way...
> > >
> > > fileSystemManager = new
> > > org.apache.commons.vfs2.impl.StandardFileSystemManager();
> > > fileSystemManager.setLogger(null);
> > > try {
> > >  fileSystemManager.init();
> > >  fileSystemManager.setBaseFile(new File(""));
> > > } catch (FileSystemException e) {
> > >  e.printStackTrace();
> > > }
> > >
> > > Xeno Amess  于2020年1月19日周日 下午6:08写道：
> > >>
> > >> I'm trying to migrate to commons-vfs2 now
> > >> severial things I found not quite right / amazing.
> > >>
> > >> 1.
> > >>   I tested version 2.6.0 and 2.5.0, and I just start at
> > >> VSF.getManager() (of cause I have no additional contfigure or
> > >> something)
> > >>
> > >> It said class not
> > >> found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider
> > >>
> > >> And I looked into your binary jars I get from maven central (2.6.0).
> > >>
> > >> they really do not have that class WebdavFileProvider.
> > >> (even not found that package org.apache.commons.vfs2.provider.webdav)
> > >>
> > >> And after I downgrade to 2.3 (I really wonder why 2.3 not 2.3.0 but
> > >> that is not important)
> > >> It can run now.(and never tell me class not found again)
> > >> I dont't want to try 2.4.0. Really bad connection here(I'm in a villige 
> > >> now).
> > >> All I get is:
> > >> 2.6.0, broken.
> > >> 2.5.0, broken.
> > >> 2.3, fine.
> > >>
> > >> According to the file on github, it said it might be deprecated, so I
> > >> wonder if you already deprecate d it and you just forgotten it?
> > >>
> > >>   btw, according to your webpage 
> > >> https://commons.apache.org/proper/commons-vfs/
> > >> there even do not exist 2.6.0
> > >> But there be a 2.6.0 in maven central.
> > >> really make me confused.
> > >>
> > >> 2.
> > >> for using commons-vfs2 I downgrade slf4j from 2.0.0alpha to 1.7.30
> > >> We all know slf4j's author really do not care about backward
> > >> maintenance or something.
> > >> His codes are never able to migrate.
> > >> even though, will there be some plan about using reflect or something
> > >> to make vfs2 CAN suit slf4j 2.0?
> > >>
> > >> 3.
> > >> for some reason I need to deal with relative file path.
> > >> Is there any guide about using relative file path in vfs2?
> > >
> > > -
> > > 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

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

yep that make sense.
but I'd rather add a class-check for provider class.
there already be a mechanism for making sure if all classes needed for
this provider class exist -> if not then just do not add the provider.
I will add a similar mechanism for making sure if the provider class
itself exist -> if not then just do not add the provider.
pull request here.
https://github.com/apache/commons-vfs/pull/78

Rob Spoor  于2020年1月20日周一 上午12:13写道：
>
> It seems that when the webdav support was moved to a separate artifact,
> the developers forgot to update file
> commons-vfs2/src/main/resources/org/apache/commons/vfs2/impl/providers.xml.
> This file is used by StandardFileSystemManager to load the default
> providers.
>
> I think this warrants a fix, to move the webdav provider from this
> default providers.xml file to file
> commons-vfs2-jackrabbit1/src/main/resources/META-INF/vfs-providers.xml,
> and create the same file with the correct providers for the
> commons-vfs2-jackrabbit2 module.
>
>
> On 19/01/2020 16:57, Xeno Amess wrote:
> > OK I get where is bugged.
> > I will fix it and add a test for that never happen again.
> >
> > Xeno Amess  于2020年1月19日周日 下午11:21写道：
> >>
> >> The key point is even if I do not wanna use it I must have this
> >> class,or VFS.getManager() can never run.
> >>
> >> IMO this type of class relationship cause the project where hold this
> >> class must be added into vfs's pom as a dependency, or just move class
> >> VFS into that project aswell.
> >>
> >> Otherwise we should not let the VFS.getManager() rely on this class.
> >>
> >> Thanks for finding this class though.
> >>
> >> btw I tested 2.4, 2.4 is correct.
> >>
> >> Rob Spoor  于2020年1月19日周日 下午10:00写道：
> >>>
> >>> The class was there in release 2.4.1:
> >>> https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.4.1/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/webdav/WebdavFileProvider.java.
> >>> In the next release, 2.5.0, it can indeed no longer be found. A bit of
> >>> investigating showed that the webdav classes got moved to a new
> >>> artifact:
> >>> https://github.com/apache/commons-vfs/commit/42ff473acbb5363b88f5ab3c5fddbae7b206c1d2
> >>>
> >>> That means you can still use it, you just need to include an extra
> >>> dependency:
> >>> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit1/2.6.0
> >>>
> >>> There's apparently also a Jackrabbit 2 version available:
> >>> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit2/2.6.0
> >>>
> >>>
> >>> On 19/01/2020 11:24, Xeno Amess wrote:
> >>>> Right now I'm using something like
> >>>> this to deal with relative files.
> >>>> But I just think there might be a more elegant way...
> >>>>
> >>>> fileSystemManager = new
> >>>> org.apache.commons.vfs2.impl.StandardFileSystemManager();
> >>>> fileSystemManager.setLogger(null);
> >>>> try {
> >>>>   fileSystemManager.init();
> >>>>   fileSystemManager.setBaseFile(new File(""));
> >>>> } catch (FileSystemException e) {
> >>>>   e.printStackTrace();
> >>>> }
> >>>>
> >>>> Xeno Amess  于2020年1月19日周日 下午6:08写道：
> >>>>>
> >>>>> I'm trying to migrate to commons-vfs2 now
> >>>>> severial things I found not quite right / amazing.
> >>>>>
> >>>>> 1.
> >>>>>I tested version 2.6.0 and 2.5.0, and I just start at
> >>>>> VSF.getManager() (of cause I have no additional contfigure or
> >>>>> something)
> >>>>>
> >>>>> It said class not
> >>>>> found:org.apache.commons.vfs2.provider.webdav.WebdavFileProvider
> >>>>>
> >>>>> And I looked into your binary jars I get from maven central (2.6.0).
> >>>>>
> >>>>> they really do not have that class WebdavFileProvider.
> >>>>> (even not found that package org.apache.commons.vfs2.provider.webdav)
> >>>>>
> >>>>> And after I downgrade to 2.3 (I really wonder why 2.3 not 2.3.0 but
> >>>>> that is not important)
> >>>>> It can run now.(and never tell me class not found again)
> >>>>> I dont&#

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

and there comes one more question:
how to transfer a FileObject(vfs) to a File(in Java) (if possible)?
I know that sonds insane but sometimes we just need a function like this.
I tried

try {
result = new File(fileObject.getURL().toURI());
} catch (URISyntaxException | FileSystemException e) {
LOGGER.error("this FileObject cannot be transformed to a File", e);
}

it works in normal cases but when your path contains character space
in them, it will throw URISyntaxException
seems vfs and java holds different rules about space in file path?
and how should I achieve this?

Xeno Amess  于2020年1月20日周一 上午12:41写道：
>
> yep that make sense.
> but I'd rather add a class-check for provider class.
> there already be a mechanism for making sure if all classes needed for
> this provider class exist -> if not then just do not add the provider.
> I will add a similar mechanism for making sure if the provider class
> itself exist -> if not then just do not add the provider.
> pull request here.
> https://github.com/apache/commons-vfs/pull/78
>
> Rob Spoor  于2020年1月20日周一 上午12:13写道：
> >
> > It seems that when the webdav support was moved to a separate artifact,
> > the developers forgot to update file
> > commons-vfs2/src/main/resources/org/apache/commons/vfs2/impl/providers.xml.
> > This file is used by StandardFileSystemManager to load the default
> > providers.
> >
> > I think this warrants a fix, to move the webdav provider from this
> > default providers.xml file to file
> > commons-vfs2-jackrabbit1/src/main/resources/META-INF/vfs-providers.xml,
> > and create the same file with the correct providers for the
> > commons-vfs2-jackrabbit2 module.
> >
> >
> > On 19/01/2020 16:57, Xeno Amess wrote:
> > > OK I get where is bugged.
> > > I will fix it and add a test for that never happen again.
> > >
> > > Xeno Amess  于2020年1月19日周日 下午11:21写道：
> > >>
> > >> The key point is even if I do not wanna use it I must have this
> > >> class,or VFS.getManager() can never run.
> > >>
> > >> IMO this type of class relationship cause the project where hold this
> > >> class must be added into vfs's pom as a dependency, or just move class
> > >> VFS into that project aswell.
> > >>
> > >> Otherwise we should not let the VFS.getManager() rely on this class.
> > >>
> > >> Thanks for finding this class though.
> > >>
> > >> btw I tested 2.4, 2.4 is correct.
> > >>
> > >> Rob Spoor  于2020年1月19日周日 下午10:00写道：
> > >>>
> > >>> The class was there in release 2.4.1:
> > >>> https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.4.1/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/webdav/WebdavFileProvider.java.
> > >>> In the next release, 2.5.0, it can indeed no longer be found. A bit of
> > >>> investigating showed that the webdav classes got moved to a new
> > >>> artifact:
> > >>> https://github.com/apache/commons-vfs/commit/42ff473acbb5363b88f5ab3c5fddbae7b206c1d2
> > >>>
> > >>> That means you can still use it, you just need to include an extra
> > >>> dependency:
> > >>> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit1/2.6.0
> > >>>
> > >>> There's apparently also a Jackrabbit 2 version available:
> > >>> https://mvnrepository.com/artifact/org.apache.commons/commons-vfs2-jackrabbit2/2.6.0
> > >>>
> > >>>
> > >>> On 19/01/2020 11:24, Xeno Amess wrote:
> > >>>> Right now I'm using something like
> > >>>> this to deal with relative files.
> > >>>> But I just think there might be a more elegant way...
> > >>>>
> > >>>> fileSystemManager = new
> > >>>> org.apache.commons.vfs2.impl.StandardFileSystemManager();
> > >>>> fileSystemManager.setLogger(null);
> > >>>> try {
> > >>>>   fileSystemManager.init();
> > >>>>   fileSystemManager.setBaseFile(new File(""));
> > >>>> } catch (FileSystemException e) {
> > >>>>   e.printStackTrace();
> > >>>> }
> > >>>>
> > >>>> Xeno Amess  于2020年1月19日周日 下午6:08写道：
> > >>>>>
> > >>>>> I'm trying to migrate to commons-vfs2 now
> > >>>>> severial things I found not quite right / amazing.
> &g

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

[Xeno Amess]

I put it in dev-list because I really donot know wether it be a bug or not.
If it be a but then I'm actually willing for help.
But it seems by design but not a bug here, so I apologize.
Still, some questions hold.

/**
 * Returns a URL representing this file.
 *
 * @return the URL for the file.
 * @throws FileSystemException if an error occurs.
 */
URL getURL() throws FileSystemException;
that is the comments on getURL()
And IMO that is quite confusing actually.
You see if we use the same URL class and return it in such a public
method, it be normally to think it fit Java's standard, and can use
.URI if the protocol should be able to.
But the truth is the standard we used in vfs is sometimes different than Java.
The word [Sometimes] here is very dangerous and might be a bug causer,
because it can pass most tests and make users feel "Oh, it just return
a normal URL, and it really works right."
So IMO at least we shall add some more warning about "not using this
returned URL's some functions,including to URL, they might be
dangerous" or "we use different standard about file:// than Java's
file://"

Besides, I wonder why we must use a same URL class in vfs, if we
cannot guarantee it works consistently to Java lib?
Is it a better thought to create a new VFSURL class for URL in vfs?

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

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

Likely but not exactly.
the provider I missed im my case here is
[org.apache.commons.vfs2.provider.webdav.WebdavFileProvider]
and the required classes are [org.apache.commons.httpclient.HttpClient] and
[org.apache.jackrabbit.webdav.client.methods.DavMethod]

I went analyze my pom.
I use


org.codehaus.mojo
versions-maven-plugin
2.7


[versions-maven-plugin] use [maven-plugin-plugin] to generate plugin.xml,
and which contains


  org.apache.maven.wagon
  wagon-webdav-jackrabbit
  jar
  1.0-beta-6


so [wagon-webdav-jackrabbit] contains
[org.apache.jackrabbit.webdav.client.methods.BaseDavRequest]

[versions-maven-plugin] use [maven-plugin-plugin] to generate plugin.xml,
and which also contains


  commons-httpclient
  commons-httpclient
  jar
  3.0


so [commons-httpclient] contains [org.apache.commons.httpclient.HttpClient]


*So things goes clear here.Every project who have [versions-maven-plugin]
2.7 as dependency will not start VFS normally.*

versions-maven-plugin is a plugin for auto upgrade version num in pom, and
is really useful to me.
I have no idea about why [versions-maven-plugin]'s author need do this.

besides.

  [versions-maven-plugin]'s plugin.xml contains some things like jackrabbit.
and yeah there be 3 jackrabbit libs.
I have no idea whether they invoke each other or what.
I just hope this can be a little useful for you.


  org.apache.maven.wagon
  wagon-webdav-jackrabbit
  jar
  1.0-beta-6


  org.apache.jackrabbit
  jackrabbit-webdav
  jar
  1.5.0


  org.apache.jackrabbit
  jackrabbit-jcr-commons
  jar
  1.5.0


besides.

I really think split one java package into several maven project be
dangerous.



Woonsan Ko  于2020年1月24日周五 上午1:03写道：

> On Sun, Jan 19, 2020 at 11:41 AM Xeno Amess  wrote:
> >
> > yep that make sense.
> > but I'd rather add a class-check for provider class.
> > there already be a mechanism for making sure if all classes needed for
> > this provider class exist -> if not then just do not add the provider.
> > I will add a similar mechanism for making sure if the provider class
> > itself exist -> if not then just do not add the provider.
> > pull request here.
> > https://github.com/apache/commons-vfs/pull/78
>
> I thought the nested if-available elements [1] would do necessary
> checks before attempting to create the provider. In my understanding,
> if the required class doesn't exist, then the provider won't be
> created.
> So, in your case, do you have both org.apache.http.client.HttpClient
> and org.apache.jackrabbit.webdav.client.methods.BaseDavRequest, but
> not have commons-vfs2-jackrabbit1-2.5.0? Is it why you met the
> problem?
>
> Regards,
>
> Woonsan
>
> [1]
> https://github.com/apache/commons-vfs/blob/rel/commons-vfs-2.5.0/commons-vfs2/src/main/resources/org/apache/commons/vfs2/impl/providers.xml#L107-L108
>
> >
> > Rob Spoor  于2020年1月20日周一 上午12:13写道：
> > >
> > > It seems that when the webdav support was moved to a separate artifact,
> > > the developers forgot to update file
> > >
> commons-vfs2/src/main/resources/org/apache/commons/vfs2/impl/providers.xml.
> > > This file is used by StandardFileSystemManager to load the default
> > > providers.
> > >
> > > I think this warrants a fix, to move the webdav provider from this
> > > default providers.xml file to file
> > > commons-vfs2-jackrabbit1/src/main/resources/META-INF/vfs-providers.xml,
> > > and create the same file with the correct providers for the
> > > commons-vfs2-jackrabbit2 module.
> > >
> > >
> > > On 19/01/2020 16:57, Xeno Amess wrote:
> > > > OK I get where is bugged.
> > > > I will fix it and add a test for that never happen again.
> > > >
> > > > Xeno Amess  于2020年1月19日周日 下午11:21写道：
> > > >>
> > > >> The key point is even if I do not wanna use it I must have this
> > > >> class,or VFS.getManager() can never run.
> > > >>
> > > >> IMO this type of class relationship cause the project where hold
> this
> > > >> class must be added into vfs's pom as a dependency, or just move
> class
> > > >> VFS into that project aswell.
> > > >>
> > > >> Otherwise we should not let the VFS.getManager() rely on this class.
> > > >>
> > > >> Thanks for finding this class though.
> > > >>
> > > >> btw I tested 2.4, 2.4 is correct.
> > > >>
> > > >> Rob Spoor  于2020年1月19日周日 下午10:00写道：
> > > >>>
> > > >>> The class was there in

Re: some questions (/bug?) about commons-vfs2 make me confused.

[Xeno Amess]

Yep,that can do...
I upgrade vfs to 2.6 and tried adding commons-vfs2-jackrabbit1 and 2 and it
can work correctly now.
thx for your help guys.

Woonsan Ko  于2020年1月24日周五 上午4:05写道：

> On Thu, Jan 23, 2020 at 2:44 PM Xeno Amess  wrote:
> >
> > Likely but not exactly.
> > the provider I missed im my case here is
> > [org.apache.commons.vfs2.provider.webdav.WebdavFileProvider]
> > and the required classes are [org.apache.commons.httpclient.HttpClient]
> and
> > [org.apache.jackrabbit.webdav.client.methods.DavMethod]
> >
> > I went analyze my pom.
> > I use
> >
> > 
> > org.codehaus.mojo
> > versions-maven-plugin
> > 2.7
> > 
> >
> > [versions-maven-plugin] use [maven-plugin-plugin] to generate plugin.xml,
> > and which contains
> >
> > 
> >   org.apache.maven.wagon
> >   wagon-webdav-jackrabbit
> >   jar
> >   1.0-beta-6
> > 
> >
> > so [wagon-webdav-jackrabbit] contains
> > [org.apache.jackrabbit.webdav.client.methods.BaseDavRequest]
> >
> > [versions-maven-plugin] use [maven-plugin-plugin] to generate plugin.xml,
> > and which also contains
> >
> > 
> >   commons-httpclient
> >   commons-httpclient
> >   jar
> >   3.0
> > 
> >
> > so [commons-httpclient] contains
> [org.apache.commons.httpclient.HttpClient]
> >
> >
> > *So things goes clear here.Every project who have [versions-maven-plugin]
> > 2.7 as dependency will not start VFS normally.*
>
> Thank you very much for your thorough analysis!
> So, the problem may occur when commons-vfs2-jackrabbit1 doesn't exist
> whereas the required classes (if-available elements) exist. A
> temporary workaround could be just to add commons-vfs2-jackrabbit1
> dependency. Of course it's not a real fix.
>
> Back to your PR, I saw you suggest checking the provider class itself
> and skipping if the provider class is unavailable.
> Another approach is to add one more if-available element in the
> providers.xml to make sure whether the _specific_ provider can be
> loaded or not.
> For example, if we added
> 'org.apache.commons.vfs2.provider.webdav.WebdavFileSystem' as a new
> if-available element, it would work too.
> ('org.apache.commons.vfs2.provider.webdav4.Webdav4FileSystem' for
> webdav4 and webdav4s likewise.)
> This approach seems better to me because we can keep the "fail-fast"
> behavior if a provider class is wrong or misconfigured and the fix is
> provider-specific.
>
> Regards,
>
> Woonsan
>
> >
> > versions-maven-plugin is a plugin for auto upgrade version num in pom,
> and
> > is really useful to me.
> > I have no idea about why [versions-maven-plugin]'s author need do this.
> >
> > besides.
> >
> >   [versions-maven-plugin]'s plugin.xml contains some things like
> jackrabbit.
> > and yeah there be 3 jackrabbit libs.
> > I have no idea whether they invoke each other or what.
> > I just hope this can be a little useful for you.
> >
> > 
> >   org.apache.maven.wagon
> >   wagon-webdav-jackrabbit
> >   jar
> >   1.0-beta-6
> > 
> > 
> >   org.apache.jackrabbit
> >   jackrabbit-webdav
> >   jar
> >   1.5.0
> > 
> > 
> >   org.apache.jackrabbit
> >   jackrabbit-jcr-commons
> >   jar
> >   1.5.0
> > 
> >
> > besides.
> >
> > I really think split one java package into several maven project be
> > dangerous.
> >
> >
> >
> > Woonsan Ko  于2020年1月24日周五 上午1:03写道：
> >
> > > On Sun, Jan 19, 2020 at 11:41 AM Xeno Amess 
> wrote:
> > > >
> > > > yep that make sense.
> > > > but I'd rather add a class-check for provider class.
> > > > there already be a mechanism for making sure if all classes needed
> for
> > > > this provider class exist -> if not then just do not add the
> provider.
> > > > I will add a similar mechanism for making sure if the provider class
> > > > itself exist -> if not then just do not add the provider.
> > > > pull request here.
> > > > https://github.com/apache/commons-vfs/pull/78
> > >
> > > I thought the nested if-available elements [1] would do necessary
> > > checks before attempting to create the provider. In my understanding,
> > > if the required class doesn't exist, then the provider won't be
> > > created.
> > > So, in your case, do

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

[Xeno Amess]

Collector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:248)
at
org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$5(DefaultLauncher.java:211)
at
org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:226)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:199)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:132)
at
com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)


Process finished with exit code 0

We can skip the log4j part, then you can see, the url parser in javaio
cannot deal with " ", and " " must be transcoded to "%20", and if not do so
in URL, then url.toURI() will fail.



Bernd Eckenfels  于2020年1月24日周五 上午4:21写道：

> Hello,
>
> I am not sure I understand what the actual difference is, but you are
> right, the URL should actually be useable. However there are a lot of
> inconsistencies and backward compatibilities to look out for (even File
> itself has different URL/URI methods and never defined how Windows drives
> are to be handled). So can you give us an example path and what it looks
> like in URL from VFS and from java.io, so we can check if there is
> something to tweak.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Xeno Amess 
> Gesendet: Thursday, January 23, 2020 2:40:59 PM
> An: Commons Developers List 
> Betreff: Re: Getting File of FileObject (was: some questions (/bug?) about
> commons-vfs2 make me confused.)
>
> I put it in dev-list because I really donot know wether it be a bug or not.
> If it be a but then I'm actually willing for help.
> But it seems by design but not a bug here, so I apologize.
> Still, some questions hold.
>
> /**
>  * Returns a URL representing this file.
>  *
>  * @return the URL for the file.
>  * @throws FileSystemException if an error occurs.
>  */
> URL getURL() throws FileSystemException;
> that is the comments on getURL()
> And IMO that is quite confusing actually.
> You see if we use the same URL class and return it in such a public
> method, it be normally to think it fit Java's standard, and can use
> .URI if the protocol should be able to.
> But the truth is the standard we used in vfs is sometimes different than
> Java.
> The word [Sometimes] here is very dangerous and might be a bug causer,
> because it can pass most tests and make users feel "Oh, it just return
> a normal URL, and it really works right."
> So IMO at least we shall add some more warning about "not using this
> returned URL's some functions,including to URL, they might be
> dangerous" or "we use different standard about file:// than Java's
> file://"
>
> Besides, I wonder why we must use a same URL class in vfs, if we
> cannot guarantee it works consistently to Java lib?
> Is it a better thought to create a new VFSURL class for URL in vfs?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

[Xeno Amess]

e.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1507)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1507)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:248)
at
org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$5(DefaultLauncher.java:211)
at
org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:226)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:199)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:132)
at
com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)


Process finished with exit code 0

(I forgot to refresh the console. sorry.)
(Although I guess you can get what I mean)

Xeno Amess  于2020年1月24日周五 上午6:26写道：

> OK>
> 1. I use win10, jdk 13 here.
> 2. make a file [D:/1 1.txt] , there is a character space between the two
> character '1'.
> 3. run a code like this.
>
> /*
>  * MIT License
>  *
>  * Copyright (c) 2020 XenoAmess
>  *
>  * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
>  * of this software and associated documentation files (the "Software"), to 
> deal
>  * in the Software without restriction, including without limitation the 
> rights
>  * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>  * copies of the Software, and to permit persons to whom the Software is
>  * furnished to do so, subject to the following conditions:
>  *
>  * The above copyright notice and this permission notice shall be included in 
> all
>  * copies or substantial portions of the Software.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>  * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>  * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
>  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR 

Re: [numbers] Complex to use code ported with a permissive licence

[Xeno Amess]

how about create a new project who contains the modified source function
and original license，and in commons we just invoke that function？

Alex Herbert  于 2020年1月24日周五 上午8:42写道：

>
>
> > On 24 Jan 2020, at 00:07, Gilles Sadowski  wrote:
> >
> > Hello.
> >
> > 2020-01-24 0:30 UTC+01:00, Alex Herbert  >:
> >> In short:
> >>
> >> - Math.hypot is required in Complex to compute sqrt(x^2 + y^2) without
> >> over/underflow to 1 ULP precision.
> >> - Complex also requires the same computation without the sqrt or
> >> over/underflow protection
> >> - I found the reference for Math.hypot and reimplemented the function
> >> - My port is 4x faster than Math.hypot and the same accuracy (or better)
> >> - I will add this as a private internal method in Complex
> >> - The source for the port requires the original licence is maintained
> >>
> >> The question is where to put the notice of the original license? Copying
> >> from commons RNG it would be in the source method javadoc and also in
> all
> >> LICENSE.txt files through the multi-module project. This seems
> excessive. I
> >> thought perhaps to include it only in numbers parent and then the
> complex
> >> module where it applies.
> >
> > IIUC, this would agree with the recommendations here:
> >http://www.apache.org/dev/licensing-howto.html <
> http://www.apache.org/dev/licensing-howto.html>
> >
>
> That talks about LICENCE in the entire product distribution. So that would
> be the archive available from the downloads page. Then it states the
> LICENSE should be at the top level of the source tree. So parent has a
> LICENSE that covers all the additions for each sub-module.
>
> It is not clear to me about whether all modules require the same licence.
> It states
>
> "LICENSE and NOTICE must exactly represent the contents of the
> distribution they reside in.”
>
> So I would assume each module should have a LICENSE and NOTICE that
> reflects its distribution which is the module jar distributed to maven.
>
> So my interpretation is to have a LICENSE and NOTICE in each module where
> LICENSE can reflect the specific additions for that module. The parent root
> directory would combine all the additions from each LICENSE in all the
> sub-modules.
>
> This would mean the LICENSE addition for MersenneTwister can be dropped
> from all the commons modules except the commons-rng-core module. Likewise I
> would add the short license for fdlibm to numbers in the parent dir and
> only in the complex module.
>
> Please let me know if you interpret this differently.
>
> > [By the way, we should perhaps remove the ".txt" suffix.]
>
> Although the guidelines talk about LICENSE and NOTICE all the commons
> projects I checked have a .txt suffix. The commons-build plugin that
> generates the README.md file even adds links to LICENSE.txt.
>
> Looking at other apache projects they show both forms, e.g.
>
> LICENSE
> beam, spark, tomcat
>
> LICENSE.txt
> cassandra, arrow, jackrabbit-oak
>
> So I don’t think changing the .txt suffix is required. We are in the same
> boat as a lot of other projects and at least this is consistent across all
> of commons.
>
> >
> > Regards,
> > Gilles
> >
> >>
> >>
> >> Background
> >>
> >> The complex class uses the Math.hypot(double, double) function to
> determine
> >> the absolute value of a complex number x + iy as sqrt(x^2 + y^2) without
> >> over/underflow to 1 ULP precision. This is used directly (in sqrt() and
> >> abs()) but also without the square root to compute x^2 + y^2 in the
> log()
> >> function. These functions also perform over/underflow protection and so
> >> ideally just require access to the same formula for high precision x^2 +
> >> y^2. This would enable consistency across the different methods that
> use the
> >> absolute of the complex number. Currently the hypot function is very
> slow in
> >> the Complex JMH benchmark so I looked into hypot.
> >>
> >> This function is known to be slow [1] pre-Java 9 which I was using for
> >> benchmarking. I found that in Java 9 the code was changed from calling a
> >> native function to an implementation in Java of the "Freely
> Distributable
> >> Maths Library" [2]. The JMH benchmark for complex shows an improvement
> >> between Java 8 and 9 of about 7-fold speed increase. However this does
> not
> >> allow access to the same computation without the square root. The source
> >> code for fdlibm has a permission license [3] so I have implemented a
> port
> >> that allows separation of the x^2 + y^2 computation from the sqrt and
> the
> >> overflow protection.
> >>
> >> In testing my ported version I found cases where it was more accurate
> than
> >> the Java reference, but none where it was less accurate. I attribute
> this to
> >> the different implementation of splitting a number into parts for high
> >> precision that is different in my port from the original. I used the
> split
> >> that is already present in Complex. I tested side-by-side an alternative
>

Re: [numbers] Complex to use code ported with a permissive licence

[Xeno Amess]

the new project just use the original license.

获取 Outlook for Android<https://aka.ms/ghei36>


From: Gilles Sadowski 
Sent: Friday, January 24, 2020 5:43:49 PM
To: Commons Developers List 
Subject: Re: [numbers] Complex to use code ported with a permissive licence

Hi.

2020-01-24 5:21 UTC+01:00, Xeno Amess :
> how about create a new project who contains the modified source function
> and original license，and in commons we just invoke that function？
>

Then, the same question(s) will be asked for that new project (?).

Regards,
Gilles

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

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

[Xeno Amess]

File(FileObject.getName().getPathDecoded())

yep I use this now.
it works correctly(at least in my usecase)

Bernd Eckenfels  于 2020年1月24日周五 下午5:02写道：

> Hello,
>
> I think FileObject#getURL() suffers from the same(similar) encoding
> problems as File#toURL did. It proofed to be hard to change file, so we
> should I guess not do it for FileObject:
>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=61794
>
> One option would be to add a FileObject#getURI()?
>
> Having said that, I would still use new
> File(FileObject.getName().getPathDecoded()) instead.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Xeno Amess 
> Gesendet: Thursday, January 23, 2020 11:45:21 PM
> An: Commons Developers List 
> Betreff: Re: Getting File of FileObject (was: some questions (/bug?) about
> commons-vfs2 make me confused.)
>
> class org.apache.commons.httpclient.HttpClient
> interface org.apache.jackrabbit.webdav.client.methods.DavMethod
> log4j: Parsing for [root] with value=[DEBUG,DEBUG_LOG,ERROR_LOG].
> log4j: Level token is [DEBUG].
> log4j: Category root set to DEBUG
> log4j: Parsing appender named "DEBUG_LOG".
> log4j: Parsing layout options for "DEBUG_LOG".
> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}  [
> %t:%r ] - [ %p ]  %m%n].
> log4j: End of parsing for "DEBUG_LOG".
> log4j: Setting property [threshold] to [DEBUG].
> log4j: Setting property [file] to [logs/logs.log].
> log4j: Setting property [append] to [true].
> log4j: setFile called: logs/logs.log, true
> log4j: setFile ended
> log4j: Appender [DEBUG_LOG] to be rolled at midnight.
> log4j: Parsed "DEBUG_LOG" options.
> log4j: Parsing appender named "ERROR_LOG".
> log4j: Parsing layout options for "ERROR_LOG".
> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}  [
> %t:%r ] - [ %p ]  %m%n].
> log4j: End of parsing for "ERROR_LOG".
> log4j: Setting property [file] to [logs/error.log].
> log4j: Setting property [threshold] to [ERROR].
> log4j: Setting property [append] to [true].
> log4j: setFile called: logs/error.log, true
> log4j: setFile ended
> log4j: Appender [ERROR_LOG] to be rolled at midnight.
> log4j: Parsed "ERROR_LOG" options.
> log4j: Finished configuring.
> File : file:/D:/1%201.txt
> FileObject : file:///D:/1 1.txt
> D:\1 1.txt
> java.net.URISyntaxException: Illegal character in path at index 12:
> file:///D:/1 1.txt
> at java.base/java.net.URI$Parser.fail(URI.java:2936)
> at java.base/java.net.URI$Parser.checkChars(URI.java:3107)
> at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3189)
> at java.base/java.net.URI$Parser.parse(URI.java:3137)
> at java.base/java.net.URI.(URI.java:623)
> at java.base/java.net.URL.toURI(URL.java:1048)
> at FileManagerTest.test(FileManagerTest.java:66)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
>
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
> at
>
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
>
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
>
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
>
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
>
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
>
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
>
> or

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

[Xeno Amess]

also suggest adding come comments for toURL to aware users of this problem.

Xeno Amess  于 2020年1月24日周五 下午5:51写道：

> File(FileObject.getName().getPathDecoded())
>
> yep I use this now.
> it works correctly(at least in my usecase)
>
> Bernd Eckenfels  于 2020年1月24日周五 下午5:02写道：
>
>> Hello,
>>
>> I think FileObject#getURL() suffers from the same(similar) encoding
>> problems as File#toURL did. It proofed to be hard to change file, so we
>> should I guess not do it for FileObject:
>>
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=61794
>>
>> One option would be to add a FileObject#getURI()?
>>
>> Having said that, I would still use new
>> File(FileObject.getName().getPathDecoded()) instead.
>>
>> Gruss
>> Bernd
>>
>>
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: Xeno Amess 
>> Gesendet: Thursday, January 23, 2020 11:45:21 PM
>> An: Commons Developers List 
>> Betreff: Re: Getting File of FileObject (was: some questions (/bug?)
>> about commons-vfs2 make me confused.)
>>
>> class org.apache.commons.httpclient.HttpClient
>> interface org.apache.jackrabbit.webdav.client.methods.DavMethod
>> log4j: Parsing for [root] with value=[DEBUG,DEBUG_LOG,ERROR_LOG].
>> log4j: Level token is [DEBUG].
>> log4j: Category root set to DEBUG
>> log4j: Parsing appender named "DEBUG_LOG".
>> log4j: Parsing layout options for "DEBUG_LOG".
>> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}
>> [
>> %t:%r ] - [ %p ]  %m%n].
>> log4j: End of parsing for "DEBUG_LOG".
>> log4j: Setting property [threshold] to [DEBUG].
>> log4j: Setting property [file] to [logs/logs.log].
>> log4j: Setting property [append] to [true].
>> log4j: setFile called: logs/logs.log, true
>> log4j: setFile ended
>> log4j: Appender [DEBUG_LOG] to be rolled at midnight.
>> log4j: Parsed "DEBUG_LOG" options.
>> log4j: Parsing appender named "ERROR_LOG".
>> log4j: Parsing layout options for "ERROR_LOG".
>> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}
>> [
>> %t:%r ] - [ %p ]  %m%n].
>> log4j: End of parsing for "ERROR_LOG".
>> log4j: Setting property [file] to [logs/error.log].
>> log4j: Setting property [threshold] to [ERROR].
>> log4j: Setting property [append] to [true].
>> log4j: setFile called: logs/error.log, true
>> log4j: setFile ended
>> log4j: Appender [ERROR_LOG] to be rolled at midnight.
>> log4j: Parsed "ERROR_LOG" options.
>> log4j: Finished configuring.
>> File : file:/D:/1%201.txt
>> FileObject : file:///D:/1 1.txt
>> D:\1 1.txt
>> java.net.URISyntaxException: Illegal character in path at index 12:
>> file:///D:/1 1.txt
>> at java.base/java.net.URI$Parser.fail(URI.java:2936)
>> at java.base/java.net.URI$Parser.checkChars(URI.java:3107)
>> at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3189)
>> at java.base/java.net.URI$Parser.parse(URI.java:3137)
>> at java.base/java.net.URI.(URI.java:623)
>> at java.base/java.net.URL.toURI(URL.java:1048)
>> at FileManagerTest.test(FileManagerTest.java:66)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> at
>>
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>>
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
>> at
>>
>> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
>> at
>>
>> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>> at
>>
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>> at
>>
>> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
>> at
>>
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
>> at
>>
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
>> at
>>
>> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
>> at
>>
>> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(Executa

Re: [poll] Beta versions should be labeled "Beta", not "B".

[Xeno Amess]

I prefer 3.0-rc1
but 3.0-beta1 sounds far better than 3.0-B1

XenoAmess


From: Gilles Sadowski 
Sent: Monday, March 30, 2020 11:37:43 PM
To: Commons Developers List 
Subject: Re: [poll] Beta versions should be labeled "Beta", not "B".

Le lun. 30 mars 2020 à 16:49, Matt Juntunen
 a écrit :
>
> +1 for "beta".

+1

Gilles

>
> -Matt
> 
> From: Rob Tompkins 
> Sent: Monday, March 30, 2020 10:25 AM
> To: Commons Developers List 
> Subject: Re: [poll] Beta versions should be labeled "Beta", not "B".
>
> I’m a +1 on “beta" over “B"
>
> It is indeed a good idea.
>
> > On Mar 30, 2020, at 10:14 AM, Gary Gregory  wrote:
> >
> > Hi All:
> >
> > I would like to update https://commons.apache.org/releases/versioning.html 
> > to
> > read:
> >
> > "Beta releases are denoted by adding "-beta" after the
> > release number. For example, if the current release version is 2.0.4, and a
> > developer wished to preview the next major release, the release would be
> > labeled 3.0-beta1"
> >
> > Thoughts?
> > Gary

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

suggest adding cache for .m2 folders into travis-ci for commons project.

[Xeno Amess]

most of commons projects use travis-ci but only few of them uses cache for
.m2
for example, commons-lang's .travis.yml looks like:

language: java
jdk:
  - openjdk8
  - openjdk11
  - openjdk13
  - openjdk-ea

matrix:
  include:
- os: linux-ppc64le
  jdk: openjdk8
  allow_failures:
- jdk: openjdk-ea

script:
  - mvn

after_success:
  - mvn clean test jacoco:report coveralls:report -Ptravis-jacoco
javadoc:javadoc -Ddoclint=all

we can easily change it to

language: java

cache:
  directories:
- "$HOME/.m2"

jdk:
  - openjdk8
  - openjdk11
  - openjdk13
  - openjdk-ea

matrix:
  include:
- os: linux-ppc64le
  jdk: openjdk8
  allow_failures:
- jdk: openjdk-ea

script:
  - mvn

after_success:
  - mvn clean test jacoco:report coveralls:report -Ptravis-jacoco
javadoc:javadoc -Ddoclint=all

https://docs.travis-ci.com/user/caching
the benifit is it will build faster on travis-ci, make everybody's life
easier.
I see no cost in doing so.
what about your opinions?

opinions about @NotNull and @Nullable ?

[Xeno Amess]

I want to know about your opinions about @NotNull and @Nullable.

Should we use it in every function?
Or we use it  only at some misleading places?
Or simply not use them at all?

thx.

Re: [configuration] org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?

[Xeno Amess]

I really think we shall have a common template for Enums

XenoAmess


From: Gary Gregory 
Sent: Monday, April 27, 2020 8:50:22 AM
To: Commons Developers List 
Subject: [configuration] 
org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?

Hi All:

I'd like to have a way to get an enum instance out of
a org.apache.commons.configuration2.ImmutableConfiguration.

I'm surprised there is nothing like a getEnum(...). Any thoughts about
adding:

default > T getEnum(String key, Class enumType) {
return Enum.valueOf(enumType, getString(key));
}

default > T getEnum(String key, Class enumType, String
defaultEnum) {
return Enum.valueOf(enumType, getString(key, defaultEnum));
}

?
Gary

Re: [commons-lang3] potential bug in CharSequenceUtils?

[Xeno Amess]

yes it is really a bug.
I created a fix pr (with test codes) at
https://github.com/apache/commons-lang/pull/529
check in it when you guys have time.


Xeno Amess  于2020年4月29日周三 上午5:04写道：

> well when I look at StringUtil I found something like this.
>
> final char c1 = cs.charAt(index1++);
> final char c2 = substring.charAt(index2++);
>
> if (c1 == c2) {
> continue;
> }
>
> if (!ignoreCase) {
> return false;
> }
>
> // The same check as in String.regionMatches():
> if (Character.toUpperCase(c1) != Character.toUpperCase(c2)
> && Character.toLowerCase(c1) != Character.toLowerCase(c2)) {
> return false;
> }
>
> But it actually is not quite same to what in String.regionMatches.
> the code part in String.regionMatches. in JKD8 is actually
>
> char c1 = ta[to++];
> char c2 = pa[po++];
> if (c1 == c2) {
> continue;
> }
> if (ignoreCase) {
> // If characters don't match but case may be ignored,
> // try converting both characters to uppercase.
> // If the results match, then the comparison scan should
> // continue.
> char u1 = Character.toUpperCase(c1);
> char u2 = Character.toUpperCase(c2);
> if (u1 == u2) {
> continue;
> }
> // Unfortunately, conversion to uppercase does not work properly
> // for the Georgian alphabet, which has strange rules about case
> // conversion.  So we need to make one last check before
> // exiting.
> if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
> continue;
> }
> }
>
> see, the chars to invoke Character.toLowerCase is actually u1 and u2, but
> according to logic  in CharSequenceUtils they should be c1 and c2.
> If they are functional equal, then why oracle guys create the two
> variables u1 and u2? That is a waste of time then.
> So I think it might be a bug.
> But me myself know nothing about Georgian.
> Is there anybody familiar with Georgian alphabet and willing to do further
> debug about this?
>
>
>

Re: [LANG] Porting to Kotlin

[Xeno Amess]

Hi.
If you mean this then I will be a +1 instead.
Just, do not convert anything original java code to kotlin, and make sure
pure java user will not be affected.
And I don't really mind if you add some kotlin util class dealing with
kotlin things.


Isira Seneviratne  于2020年5月10日周日 下午9:33写道：

> On Sun, May 10, 2020, 6:55 PM Gilles Sadowski 
> wrote:
>
> > Hi.
> >
> > In what consists the "porting"?  Could you give an example?
> >
>
> Of course.
>
> Extension functions and properties are a language feature of Kotlin, which
> allow a function/property to be called from a variable as if it was part of
> the original class declaration:
> https://kotlinlang.org/docs/reference/extensions.html
>
>
> > If it's straightforward and can be automated, it might be worth
> > creating the port for all the Commons components (as part of
> > the release) in a move that can potentially expand our team of
> > developers (if Kotlin programmers are willing to participate to
> > the "upstream" Java project, of course).
> >
> > Regards,
> > Gilles
> >
> > >> [...]
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

[apache/commons-email] consider about putting it to github?

[Xeno Amess]

Hi.
I see no newer release are made for this project for several years.
So I have several questions.
1. Is this project still alive?
2. Should we move it to github?
3. Link http://svn.apache.org/viewvc/commons/proper/email/trunk said 403
forbidden to me, does that means usual user cannot get the repo?
svn command line also fails.
>svn checkout https://svn.apache.org/repos/asf/commons/proper/email/trunk
commons-email
svn: E17: URL '
https://svn.apache.org/repos/asf/commons/proper/email/trunk' doesn't exist

4.Yes I can see the released codes, but with no commit history.

Thanks.

Re: [apache/commons-email] consider about putting it to github?

[Xeno Amess]

thanks
then please change the descriptions in
https://commons.apache.org/proper/commons-email/source-repository.html to
avoid these kind of things.

Gilles Sadowski  于2020年5月11日周一 上午5:18写道：

> 2020-05-10 23:13 UTC+02:00, Xeno Amess :
> > Hi.
> > I see no newer release are made for this project for several years.
> > So I have several questions.
> > 1. Is this project still alive?
> > 2. Should we move it to github?
> > 3. Link http://svn.apache.org/viewvc/commons/proper/email/trunk said 403
> > forbidden to me, does that means usual user cannot get the repo?
> > svn command line also fails.
> >>svn checkout https://svn.apache.org/repos/asf/commons/proper/email/trunk
> > commons-email
> > svn: E17: URL '
> > https://svn.apache.org/repos/asf/commons/proper/email/trunk' doesn't
> exist
>
> https://gitbox.apache.org/repos/asf?p=commons-email.git
>
> HTH,
> Gilles
>
> >
> > 4.Yes I can see the released codes, but with no commit history.
> >
> > Thanks.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COMPRESS] Travis build fail with JDK14

[Xeno Amess]

my opinion: until you are sure the master can pass jdk14, move it to [allow
failure].
here is an example.
https://github.com/apache/commons-vfs/commit/249d1dc9fb3f2bd5209aaa299c4ed61414f1fd78#diff-354f30a63fb0907d4ad57269548329e3


adding a unpassable check in travis will makes all pull requests/commit
return builld failure, which will hide problem and make checker's life hard.

Stefan Bodewig  于2020年5月13日周三 下午10:46写道：

> On 2020-05-13, Peter Lee wrote:
>
> >  Hi,all
>
> > The travis build of Compress is failing now cause the openjdk14 was added
> > to travis.yml recently. The reason is the Pack200 was removed from JDK14
> > and there was a discussion about it in January. Emmanuel is working on
> his
> > replacement project(https://github.com/pack200/pack200) but not finished
> > yet. Seems we have no good replacement for now.
>
> > I'm thinking we should disable openjdk14 in travis before we have find a
> > solution for this. WDYT?
>
> I'm fine with disabling the travis build for now.
>
> Had a quick look through JIRA as I was totally sure there must be an
> issue tracking this, but it seems I haven't created any. Anyway with the
> last release announcement I promised we'd deal with JDK14 for the next
> release - one way or the other. :-)
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COMPRESS] Travis build fail with JDK14

[Xeno Amess]

I created a pr.
https://github.com/apache/commons-compress/pull/100

Xeno Amess  于2020年5月14日周四 上午12:00写道：

> my opinion: until you are sure the master can pass jdk14, move it to
> [allow failure].
> here is an example.
>
> https://github.com/apache/commons-vfs/commit/249d1dc9fb3f2bd5209aaa299c4ed61414f1fd78#diff-354f30a63fb0907d4ad57269548329e3
>
>
> adding a unpassable check in travis will makes all pull requests/commit
> return builld failure, which will hide problem and make checker's life hard.
>
> Stefan Bodewig  于2020年5月13日周三 下午10:46写道：
>
>> On 2020-05-13, Peter Lee wrote:
>>
>> >  Hi,all
>>
>> > The travis build of Compress is failing now cause the openjdk14 was
>> added
>> > to travis.yml recently. The reason is the Pack200 was removed from JDK14
>> > and there was a discussion about it in January. Emmanuel is working on
>> his
>> > replacement project(https://github.com/pack200/pack200) but not
>> finished
>> > yet. Seems we have no good replacement for now.
>>
>> > I'm thinking we should disable openjdk14 in travis before we have find a
>> > solution for this. WDYT?
>>
>> I'm fine with disabling the travis build for now.
>>
>> Had a quick look through JIRA as I was totally sure there must be an
>> issue tracking this, but it seems I haven't created any. Anyway with the
>> last release announcement I promised we'd deal with JDK14 for the next
>> release - one way or the other. :-)
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [ JEXL] Java 6 ?

[Xeno Amess]

Hi.
As a related topic, I don't think travis-ci still supports openjdk6 in year
2020.
travis-ci does HAVE a tutorial about how to add openjdk6 at:
https://docs.travis-ci.com/user/reference/trusty/
BUT it is totally wrong.
I followed that tutorial but it failed.
https://github.com/apache/commons-jexl/blob/356f7b9c6ba931df2b8e75c8cf258c6dfecaaa70/.travis.yml

https://travis-ci.org/github/XenoAmess/commons-jexl/jobs/689474160
I have no idea why it failed nor how to run openjdk6 on travis-ci.
If anybody have any solution to solve this problem please let me know.
Thanks.

Gary Gregory  于2020年5月21日周四 上午1:14写道：

> Drop Java 6, use Java 8 from my POV. It will make builds simpler for all,
> on top of not requiring folks of installing Java 6 to make sure the tests
> pass on that platform.
>
> Use try with resources to clean up the code eventhough Java 7 would be
> enough strictly speaking.
>
> Gary
>
> On Wed, May 20, 2020, 11:09 David Barts  wrote:
>
> > Java 6 was released in December 2006, making it 13½ years old. That's
> > over 94 in computer years! (Laugh if you want but computer technology
> > goes out of date so quickly that I find treating it like dogs in this
> > regard to be a useful metric.) Oracle stopped supporting it in 2017,
> > meaning that since then the platform has not been receiving critical
> > security updates.
> >
> > I say it’s fine to drop support for it, and to make Java 8 (which is
> > still getting critical security updates) the minimum supported version.
> >
> >
> > On 5/20/20 3:47, henrib wrote:
> > > Quick poll before attempting to release JEXL 3.1;
> > > Should we still release with support for Java 6 or should we move ahead
> > with
> > > at least Java 8 ?
> > > Seems to me Java 6 is old enough to be dropped.
> > > One could still build from source with java 6 if needed.
> > > What do you think ?
> > > Cheers
> > >
> > >
> > >
> > > --
> > > Sent from:
> > http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > --
> > David Barts / n5...@me.com
> > He who has nothing to die for has nothing to live for.
> >  -- Moroccan proverb
> >
> >
>

Re: [releases,dbutils] There are 4 staged copies of dbutils-1.8

[Xeno Amess]

BTW how can a person become a PMC committer?
And if I wanna become a committer what should I do/learn?

Melloware  于2020年5月21日周四 下午11:04写道：

> Carl,
>
> It seems like there is just not enough PMC committers available for
> Commons projects.  It should not take 4 months for you to get a release
> of DButils out.  I have been trying to get Commons BeanUtils2 pushed for
> release for the last year.
>
> I know they are all volunteers and I appreciate their time, it just
> doesn't seem like there is enough PMC Committers to support all these
> Commons projects.
>
> Just my 2 cents...
>
>   Melloware
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

I just found a typo which exist in most of the commons projects.

[Xeno Amess]

in every CONTRIBUTING.md
 (for
example lang3 but actually almost every repo)

...
If you're planning to implement a new feature it makes sense to discuss
*you're* changes on the [dev list]  ...

should be

...
  If you're planning to implement a new feature it makes sense to discuss
*your* changes on the [dev list] ...

So, does it worth to fix it? or we just try to ignore it?

Re: I just found a typo which exist in most of the commons projects.

[Xeno Amess]

Ah, I go and see quite some of the repos have already fixed this typo...
So I will try to fix this typo in other repos.
thx.

Gary Gregory  于2020年5月26日周二 上午12:59写道：

> Always worth fixing IMO :-)
>
> On Mon, May 25, 2020, 12:15 Xeno Amess  wrote:
>
> > in every CONTRIBUTING.md
> > <https://github.com/apache/commons-lang/blob/master/CONTRIBUTING.md>
> (for
> > example lang3 but actually almost every repo)
> >
> > ...
> > If you're planning to implement a new feature it makes sense to discuss
> > *you're* changes on the [dev list]  ...
> >
> > should be
> >
> > ...
> >   If you're planning to implement a new feature it makes sense to discuss
> > *your* changes on the [dev list] ...
> >
> > So, does it worth to fix it? or we just try to ignore it?
> >
>

I might found the bug which cause we cannot build most projects on jdk-ea

[Xeno Amess]

We use maven-bundle-plugin, and  maven-bundle-plugin use biz.aQute.bndlib,
and there be something uncorrect in biz.aQute.bndlib running with jdk-ea, a
TreeMap thing.
I do think if I can persuade them from changing it to ConcurrentHashMap the
bug might be fixed immediately.
So first I will try to fix it in biz.aQute.bndlib, then go change
maven-bundle-plugin.
I hope this can work but I'm, just hoping.I need more learning/testing.

Re: I might found the bug which cause we cannot build most projects on jdk-ea

[Xeno Amess]

java.util.ConcurrentModificationException
1747at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
1748at java.util.TreeMap.computeIfAbsent (TreeMap.java:558)
1749at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
1750at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
1751at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
1752at java.nio.file.Files.walkFileTree (Files.java:2804)
1753at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
1754at aQute.bnd.osgi.Jar. (Jar.java:119)
1755at aQute.bnd.osgi.Jar. (Jar.java:172)
1756at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
(BundlePlugin.java:604)
1757at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
(ManifestPlugin.java:285)
1758at org.apache.felix.bundleplugin.ManifestPlugin.execute
(ManifestPlugin.java:111)
1759at org.apache.felix.bundleplugin.BundlePlugin.execute
(BundlePlugin.java:364)
1760at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
1761at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
1762at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
1763at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
1764at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
1765at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
1766at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
1767at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
1768at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
1769at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
1770at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
1771at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
1772at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
1773at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
1774at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
1775at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:64)
1776at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
1777at java.lang.reflect.Method.invoke (Method.java:564)
1778at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
1779at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
1780at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
1781at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)




https://travis-ci.org/github/apache/commons-configuration/jobs/690720767#L2142

https://travis-ci.org/github/apache/commons-bcel/jobs/690718855#L1745

Yair Zaslavsky  于2020年5月26日周二 上午9:42写道：

> I'm so mad
>
> On Mon, May 25, 2020, 6:39 PM Xeno Amess  wrote:
>
> > We use maven-bundle-plugin, and  maven-bundle-plugin use
> biz.aQute.bndlib,
> > and there be something uncorrect in biz.aQute.bndlib running with
> jdk-ea, a
> > TreeMap thing.
> > I do think if I can persuade them from changing it to ConcurrentHashMap
> the
> > bug might be fixed immediately.
> > So first I will try to fix it in biz.aQute.bndlib, then go change
> > maven-bundle-plugin.
> > I hope this can work but I'm, just hoping.I need more learning/testing.
> >
>

Re: I might found the bug which cause we cannot build most projects on jdk-ea

[Xeno Amess]

Ah, glad to hear that.
Then I can stop debugging about this problem and go back to fix travis-ci
scripts for some commons projects.

Gary Gregory  于2020年5月26日周二 上午10:38写道：

> This should be fixed in bndtool 5.1 which at the RC2 stage. The release is
> imminent.
>
> Gary
>
> On Mon, May 25, 2020, 21:39 Xeno Amess  wrote:
>
> > We use maven-bundle-plugin, and  maven-bundle-plugin use
> biz.aQute.bndlib,
> > and there be something uncorrect in biz.aQute.bndlib running with
> jdk-ea, a
> > TreeMap thing.
> > I do think if I can persuade them from changing it to ConcurrentHashMap
> the
> > bug might be fixed immediately.
> > So first I will try to fix it in biz.aQute.bndlib, then go change
> > maven-bundle-plugin.
> > I hope this can work but I'm, just hoping.I need more learning/testing.
> >
>

Re: I just found a typo which exist in most of the commons projects.

[Xeno Amess]

https://github.com/apache/commons-jcs/pull/11/files
https://github.com/apache/commons-validator/pull/23/files
https://github.com/apache/maven-enforcer/pull/68/files


Gary Gregory  于2020年5月26日周二 下午8:51写道：

> Note that the template
>
> 'commons-build-plugin/src/main/resources/commons-xdoc-templates/contributing-md-template.md'
> is correct.
>
> Gary
>
> On Tue, May 26, 2020 at 8:48 AM Gary Gregory 
> wrote:
>
> > I merged a bunch of PRs but I might have missed some in this typo area.
> > Please feel free to ping the list if we've missed some.
> >
> > TY!
> >
> > Gary
> >
> > On Mon, May 25, 2020 at 1:36 PM Xeno Amess  wrote:
> >
> >> Ah, I go and see quite some of the repos have already fixed this typo...
> >> So I will try to fix this typo in other repos.
> >> thx.
> >>
> >> Gary Gregory  于2020年5月26日周二 上午12:59写道：
> >>
> >> > Always worth fixing IMO :-)
> >> >
> >> > On Mon, May 25, 2020, 12:15 Xeno Amess  wrote:
> >> >
> >> > > in every CONTRIBUTING.md
> >> > > <https://github.com/apache/commons-lang/blob/master/CONTRIBUTING.md
> >
> >> > (for
> >> > > example lang3 but actually almost every repo)
> >> > >
> >> > > ...
> >> > > If you're planning to implement a new feature it makes sense to
> >> discuss
> >> > > *you're* changes on the [dev list]  ...
> >> > >
> >> > > should be
> >> > >
> >> > > ...
> >> > >   If you're planning to implement a new feature it makes sense to
> >> discuss
> >> > > *your* changes on the [dev list] ...
> >> > >
> >> > > So, does it worth to fix it? or we just try to ignore it?
> >> > >
> >> >
> >>
> >
>

Re: I just found a typo which exist in most of the commons projects.

[Xeno Amess]

Glad to hear that.
I knoe there must be a template but I just don't know where it be in.
I tried to find the temple several hours ago but failed lol.

Gary Gregory  于2020年5月26日周二 下午8:51写道：

> Note that the template
>
> 'commons-build-plugin/src/main/resources/commons-xdoc-templates/contributing-md-template.md'
> is correct.
>
> Gary
>
> On Tue, May 26, 2020 at 8:48 AM Gary Gregory 
> wrote:
>
> > I merged a bunch of PRs but I might have missed some in this typo area.
> > Please feel free to ping the list if we've missed some.
> >
> > TY!
> >
> > Gary
> >
> > On Mon, May 25, 2020 at 1:36 PM Xeno Amess  wrote:
> >
> >> Ah, I go and see quite some of the repos have already fixed this typo...
> >> So I will try to fix this typo in other repos.
> >> thx.
> >>
> >> Gary Gregory  于2020年5月26日周二 上午12:59写道：
> >>
> >> > Always worth fixing IMO :-)
> >> >
> >> > On Mon, May 25, 2020, 12:15 Xeno Amess  wrote:
> >> >
> >> > > in every CONTRIBUTING.md
> >> > > <https://github.com/apache/commons-lang/blob/master/CONTRIBUTING.md
> >
> >> > (for
> >> > > example lang3 but actually almost every repo)
> >> > >
> >> > > ...
> >> > > If you're planning to implement a new feature it makes sense to
> >> discuss
> >> > > *you're* changes on the [dev list]  ...
> >> > >
> >> > > should be
> >> > >
> >> > > ...
> >> > >   If you're planning to implement a new feature it makes sense to
> >> discuss
> >> > > *your* changes on the [dev list] ...
> >> > >
> >> > > So, does it worth to fix it? or we just try to ignore it?
> >> > >
> >> >
> >>
> >
>

[email and vfs] about adding class FileObjectDataSource

[Xeno Amess]

Hi.
I'm trying to maintain commons-email today, and I want to make a new class
FileObjectDataSource, who implements javax.activation.DataSource.
But things is not as easy as I want.
1. the reason.
the reason for making such a class is when last month I was doing some
school work for graduation project, and in that system I need a backend
server to send emails.
And I want to attach some FileObject (from vfs) as attachments of the
emails sent, so I have to make a class FileObjectDataSource (something
which is actually very similar to javax.activation.FileDataSource but
dealing not File but FileObject).
then I thought this class might be helpful to others, so I want to put it
into some place.
the question is, where shall I put it? commons-email, or commons-vfs?
2. commons-email.
start with commons-email.
If I make such a class into commons-email, then commons-email must add
commons-vfs as a dependency.
which sounds crazy to implement so small a feature to include a large new
dependency.
3. commons-vfs
If I make such a class into commons-vfs, then some worse things might
happen.
First, the javax.activation.DataSource is actually deleted since jdk11, and
commons-email use [jakarta.mail] for Infrastructure, whitch contains a copy
of javax.activation.DataSource.
So commons-vfs must make [jakarta.mail] as a dependency.
which sounds crazy to implement so small a feature to include a large new
dependency.
Second,  [jakarta.mail] is actually 2.0rc now, and they claimed they would
release 2.0 soon.
and in jakarta2.0, all uses of  javax.activation.DataSource will be
replaced by  jakarta.activation.DataSource.
Also, it is not actually related to vfs itself, but only a usage of vfs, so
I don't think it good to be added to vfs.
4. so maybe I should make another repo for storing such a class?
man, starting a repo for a single class sounds crazy.
5. any better ideas?

Re: [email and vfs] about adding class FileObjectDataSource

[Xeno Amess]

Yeh that is the function I used.
I want to put the class FileObjectDataSource I made to some repo, because I
think it is somehow useful, and everybody who use
commons-vfs&&commons-email will benefit from it.
but I just don't know where should I put it to.


Siegfried Goeschl  于2020年5月27日周三 下午6:11写道：

> Hi,
>
> I do not fully understand the problem - AFAIK there is an attach method
> which takes a DataSource sou can just pass your FileObjectDataSource?
>
> But I guess I miss something here :-)
>
> Thanks in advance,
>
> Siegfried Goeschl
>
>
> > On 27.05.2020, at 11:30, Xeno Amess  wrote:
> >
> > Hi.
> > I'm trying to maintain commons-email today, and I want to make a new
> class
> > FileObjectDataSource, who implements javax.activation.DataSource.
> > But things is not as easy as I want.
> > 1. the reason.
> > the reason for making such a class is when last month I was doing some
> > school work for graduation project, and in that system I need a backend
> > server to send emails.
> > And I want to attach some FileObject (from vfs) as attachments of the
> > emails sent, so I have to make a class FileObjectDataSource (something
> > which is actually very similar to javax.activation.FileDataSource but
> > dealing not File but FileObject).
> > then I thought this class might be helpful to others, so I want to put it
> > into some place.
> > the question is, where shall I put it? commons-email, or commons-vfs?
> > 2. commons-email.
> > start with commons-email.
> > If I make such a class into commons-email, then commons-email must add
> > commons-vfs as a dependency.
> > which sounds crazy to implement so small a feature to include a large new
> > dependency.
> > 3. commons-vfs
> > If I make such a class into commons-vfs, then some worse things might
> > happen.
> > First, the javax.activation.DataSource is actually deleted since jdk11,
> and
> > commons-email use [jakarta.mail] for Infrastructure, whitch contains a
> copy
> > of javax.activation.DataSource.
> > So commons-vfs must make [jakarta.mail] as a dependency.
> > which sounds crazy to implement so small a feature to include a large new
> > dependency.
> > Second,  [jakarta.mail] is actually 2.0rc now, and they claimed they
> would
> > release 2.0 soon.
> > and in jakarta2.0, all uses of  javax.activation.DataSource will be
> > replaced by  jakarta.activation.DataSource.
> > Also, it is not actually related to vfs itself, but only a usage of vfs,
> so
> > I don't think it good to be added to vfs.
> > 4. so maybe I should make another repo for storing such a class?
> > man, starting a repo for a single class sounds crazy.
> > 5. any better ideas?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [email and vfs] about adding class FileObjectDataSource

[Xeno Amess]

> I am not sure if this one class is worth the work and management overhead
for a new jar.
me neither:-)

Bernd Eckenfels  于2020年5月27日周三 下午6:19写道：

> The only clean place I could see would be a new module of VFS so it does
> not introduce a new dependency to commons-mail, I am not sure if this one
> class is worth the work and management overhead for a new jar.
>
> As sample code we could put it in the Maven site or maybe as a test
> dependency?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ____
> Von: Xeno Amess 
> Gesendet: Wednesday, May 27, 2020 12:16:22 PM
> An: Commons Developers List 
> Betreff: Re: [email and vfs] about adding class FileObjectDataSource
>
> Yeh that is the function I used.
> I want to put the class FileObjectDataSource I made to some repo, because I
> think it is somehow useful, and everybody who use
> commons-vfs&&commons-email will benefit from it.
> but I just don't know where should I put it to.
>
>
> Siegfried Goeschl  于2020年5月27日周三 下午6:11写道：
>
> > Hi,
> >
> > I do not fully understand the problem - AFAIK there is an attach method
> > which takes a DataSource sou can just pass your FileObjectDataSource?
> >
> > But I guess I miss something here :-)
> >
> > Thanks in advance,
> >
> > Siegfried Goeschl
> >
> >
> > > On 27.05.2020, at 11:30, Xeno Amess  wrote:
> > >
> > > Hi.
> > > I'm trying to maintain commons-email today, and I want to make a new
> > class
> > > FileObjectDataSource, who implements javax.activation.DataSource.
> > > But things is not as easy as I want.
> > > 1. the reason.
> > > the reason for making such a class is when last month I was doing some
> > > school work for graduation project, and in that system I need a backend
> > > server to send emails.
> > > And I want to attach some FileObject (from vfs) as attachments of the
> > > emails sent, so I have to make a class FileObjectDataSource (something
> > > which is actually very similar to javax.activation.FileDataSource but
> > > dealing not File but FileObject).
> > > then I thought this class might be helpful to others, so I want to put
> it
> > > into some place.
> > > the question is, where shall I put it? commons-email, or commons-vfs?
> > > 2. commons-email.
> > > start with commons-email.
> > > If I make such a class into commons-email, then commons-email must add
> > > commons-vfs as a dependency.
> > > which sounds crazy to implement so small a feature to include a large
> new
> > > dependency.
> > > 3. commons-vfs
> > > If I make such a class into commons-vfs, then some worse things might
> > > happen.
> > > First, the javax.activation.DataSource is actually deleted since jdk11,
> > and
> > > commons-email use [jakarta.mail] for Infrastructure, whitch contains a
> > copy
> > > of javax.activation.DataSource.
> > > So commons-vfs must make [jakarta.mail] as a dependency.
> > > which sounds crazy to implement so small a feature to include a large
> new
> > > dependency.
> > > Second,  [jakarta.mail] is actually 2.0rc now, and they claimed they
> > would
> > > release 2.0 soon.
> > > and in jakarta2.0, all uses of  javax.activation.DataSource will be
> > > replaced by  jakarta.activation.DataSource.
> > > Also, it is not actually related to vfs itself, but only a usage of
> vfs,
> > so
> > > I don't think it good to be added to vfs.
> > > 4. so maybe I should make another repo for storing such a class?
> > > man, starting a repo for a single class sounds crazy.
> > > 5. any better ideas?
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [email and vfs] about adding class FileObjectDataSource

[Xeno Amess]

Sorry, https://github.com/XenoAmess/commons-vfs2-email I mean.

Xeno Amess  于2020年5月27日周三 下午10:46写道：

> Oh as related.
> I put this poor little thing at
> https://github.com/XenoAmess/commons-vfs2-email/blob/master/pom.xml for
> now.
> If anybody need it just grab it.
>
> Xeno Amess  于2020年5月27日周三 下午6:26写道：
>
>> > I am not sure if this one class is worth the work and management
>> overhead for a new jar.
>> me neither:-)
>>
>> Bernd Eckenfels  于2020年5月27日周三 下午6:19写道：
>>
>>> The only clean place I could see would be a new module of VFS so it does
>>> not introduce a new dependency to commons-mail, I am not sure if this one
>>> class is worth the work and management overhead for a new jar.
>>>
>>> As sample code we could put it in the Maven site or maybe as a test
>>> dependency?
>>>
>>> Gruss
>>> Bernd
>>>
>>>
>>> --
>>> http://bernd.eckenfels.net
>>> 
>>> Von: Xeno Amess 
>>> Gesendet: Wednesday, May 27, 2020 12:16:22 PM
>>> An: Commons Developers List 
>>> Betreff: Re: [email and vfs] about adding class FileObjectDataSource
>>>
>>> Yeh that is the function I used.
>>> I want to put the class FileObjectDataSource I made to some repo,
>>> because I
>>> think it is somehow useful, and everybody who use
>>> commons-vfs&&commons-email will benefit from it.
>>> but I just don't know where should I put it to.
>>>
>>>
>>> Siegfried Goeschl  于2020年5月27日周三 下午6:11写道：
>>>
>>> > Hi,
>>> >
>>> > I do not fully understand the problem - AFAIK there is an attach method
>>> > which takes a DataSource sou can just pass your FileObjectDataSource?
>>> >
>>> > But I guess I miss something here :-)
>>> >
>>> > Thanks in advance,
>>> >
>>> > Siegfried Goeschl
>>> >
>>> >
>>> > > On 27.05.2020, at 11:30, Xeno Amess  wrote:
>>> > >
>>> > > Hi.
>>> > > I'm trying to maintain commons-email today, and I want to make a new
>>> > class
>>> > > FileObjectDataSource, who implements javax.activation.DataSource.
>>> > > But things is not as easy as I want.
>>> > > 1. the reason.
>>> > > the reason for making such a class is when last month I was doing
>>> some
>>> > > school work for graduation project, and in that system I need a
>>> backend
>>> > > server to send emails.
>>> > > And I want to attach some FileObject (from vfs) as attachments of the
>>> > > emails sent, so I have to make a class FileObjectDataSource
>>> (something
>>> > > which is actually very similar to javax.activation.FileDataSource but
>>> > > dealing not File but FileObject).
>>> > > then I thought this class might be helpful to others, so I want to
>>> put it
>>> > > into some place.
>>> > > the question is, where shall I put it? commons-email, or commons-vfs?
>>> > > 2. commons-email.
>>> > > start with commons-email.
>>> > > If I make such a class into commons-email, then commons-email must
>>> add
>>> > > commons-vfs as a dependency.
>>> > > which sounds crazy to implement so small a feature to include a
>>> large new
>>> > > dependency.
>>> > > 3. commons-vfs
>>> > > If I make such a class into commons-vfs, then some worse things might
>>> > > happen.
>>> > > First, the javax.activation.DataSource is actually deleted since
>>> jdk11,
>>> > and
>>> > > commons-email use [jakarta.mail] for Infrastructure, whitch contains
>>> a
>>> > copy
>>> > > of javax.activation.DataSource.
>>> > > So commons-vfs must make [jakarta.mail] as a dependency.
>>> > > which sounds crazy to implement so small a feature to include a
>>> large new
>>> > > dependency.
>>> > > Second,  [jakarta.mail] is actually 2.0rc now, and they claimed they
>>> > would
>>> > > release 2.0 soon.
>>> > > and in jakarta2.0, all uses of  javax.activation.DataSource will be
>>> > > replaced by  jakarta.activation.DataSource.
>>> > > Also, it is not actually related to vfs itself, but only a usage of
>>> vfs,
>>> > so
>>> > > I don't think it good to be added to vfs.
>>> > > 4. so maybe I should make another repo for storing such a class?
>>> > > man, starting a repo for a single class sounds crazy.
>>> > > 5. any better ideas?
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > For additional commands, e-mail: dev-h...@commons.apache.org
>>> >
>>> >
>>>
>>

Re: [email and vfs] about adding class FileObjectDataSource

[Xeno Amess]

Oh as related.
I put this poor little thing at
https://github.com/XenoAmess/commons-vfs2-email/blob/master/pom.xml for now.
If anybody need it just grab it.

Xeno Amess  于2020年5月27日周三 下午6:26写道：

> > I am not sure if this one class is worth the work and management
> overhead for a new jar.
> me neither:-)
>
> Bernd Eckenfels  于2020年5月27日周三 下午6:19写道：
>
>> The only clean place I could see would be a new module of VFS so it does
>> not introduce a new dependency to commons-mail, I am not sure if this one
>> class is worth the work and management overhead for a new jar.
>>
>> As sample code we could put it in the Maven site or maybe as a test
>> dependency?
>>
>> Gruss
>> Bernd
>>
>>
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: Xeno Amess 
>> Gesendet: Wednesday, May 27, 2020 12:16:22 PM
>> An: Commons Developers List 
>> Betreff: Re: [email and vfs] about adding class FileObjectDataSource
>>
>> Yeh that is the function I used.
>> I want to put the class FileObjectDataSource I made to some repo, because
>> I
>> think it is somehow useful, and everybody who use
>> commons-vfs&&commons-email will benefit from it.
>> but I just don't know where should I put it to.
>>
>>
>> Siegfried Goeschl  于2020年5月27日周三 下午6:11写道：
>>
>> > Hi,
>> >
>> > I do not fully understand the problem - AFAIK there is an attach method
>> > which takes a DataSource sou can just pass your FileObjectDataSource?
>> >
>> > But I guess I miss something here :-)
>> >
>> > Thanks in advance,
>> >
>> > Siegfried Goeschl
>> >
>> >
>> > > On 27.05.2020, at 11:30, Xeno Amess  wrote:
>> > >
>> > > Hi.
>> > > I'm trying to maintain commons-email today, and I want to make a new
>> > class
>> > > FileObjectDataSource, who implements javax.activation.DataSource.
>> > > But things is not as easy as I want.
>> > > 1. the reason.
>> > > the reason for making such a class is when last month I was doing some
>> > > school work for graduation project, and in that system I need a
>> backend
>> > > server to send emails.
>> > > And I want to attach some FileObject (from vfs) as attachments of the
>> > > emails sent, so I have to make a class FileObjectDataSource (something
>> > > which is actually very similar to javax.activation.FileDataSource but
>> > > dealing not File but FileObject).
>> > > then I thought this class might be helpful to others, so I want to
>> put it
>> > > into some place.
>> > > the question is, where shall I put it? commons-email, or commons-vfs?
>> > > 2. commons-email.
>> > > start with commons-email.
>> > > If I make such a class into commons-email, then commons-email must add
>> > > commons-vfs as a dependency.
>> > > which sounds crazy to implement so small a feature to include a large
>> new
>> > > dependency.
>> > > 3. commons-vfs
>> > > If I make such a class into commons-vfs, then some worse things might
>> > > happen.
>> > > First, the javax.activation.DataSource is actually deleted since
>> jdk11,
>> > and
>> > > commons-email use [jakarta.mail] for Infrastructure, whitch contains a
>> > copy
>> > > of javax.activation.DataSource.
>> > > So commons-vfs must make [jakarta.mail] as a dependency.
>> > > which sounds crazy to implement so small a feature to include a large
>> new
>> > > dependency.
>> > > Second,  [jakarta.mail] is actually 2.0rc now, and they claimed they
>> > would
>> > > release 2.0 soon.
>> > > and in jakarta2.0, all uses of  javax.activation.DataSource will be
>> > > replaced by  jakarta.activation.DataSource.
>> > > Also, it is not actually related to vfs itself, but only a usage of
>> vfs,
>> > so
>> > > I don't think it good to be added to vfs.
>> > > 4. so maybe I should make another repo for storing such a class?
>> > > man, starting a repo for a single class sounds crazy.
>> > > 5. any better ideas?
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>

[commons-el] where is commons-el?

[Xeno Amess]

https://github.com/apache/commons-el  is an empty repo.
And according to
http://commons.apache.org/dormant/commons-el/source-repository.html
I should be able to found it at http:
//svn.apache.org/viewvc/commons/proper/el/trunk
but actually returns 404.
so, what happened? is it dropped?

Re: [commons-el] where is commons-el?

[Xeno Amess]

Yes it might be there but:
Forbidden

You don't have permission to access this resource.


Bruno P. Kinoshita  于2020年5月30日周六 下午4:20写道：

> Hi,
>
> I think the code is in the dormant section now:
>
>
> http://svn.apache.org/viewvc/commons/dormant/el/trunk/http://svn.apache.org/viewvc/commons/dormant/el/
>
>
> Bruno
>
>
> On Saturday, 30 May 2020, 7:12:40 pm NZST, Xeno Amess 
> wrote:
>
>
>
>
>
> https://github.com/apache/commons-el  is an empty repo.
> And according to
> http://commons.apache.org/dormant/commons-el/source-repository.html
> I should be able to found it at http:
> //svn.apache.org/viewvc/commons/proper/el/trunk
> but actually returns 404.
> so, what happened? is it dropped?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[irc.freenode.net] or [irc.freenode.org]?

[Xeno Amess]

Hi.
I see documents in apache commons projects using [irc.freenode.net] or [
irc.freenode.org], or both of them in one same repo.
(for example commons-lang3 use irc.freenode.org in README.md but
irc.freenode.net in CONTRIBUTING.md)
Should we unify it?

Re: [commons-el] where is commons-el?

[Xeno Amess]

thanks! I will have a try.

sebb  于2020年5月30日周六 下午8:11写道：

> You should have read access to:
>
> http://svn.apache.org/repos/asf/commons/dormant/el/
> and
> http://svn.apache.org/viewvc/commons/dormant/el/
>
> On Sat, 30 May 2020 at 10:26, Xeno Amess  wrote:
> >
> > Yes it might be there but:
> > Forbidden
> >
> > You don't have permission to access this resource.
> >
> >
> > Bruno P. Kinoshita  于2020年5月30日周六 下午4:20写道：
> >
> > > Hi,
> > >
> > > I think the code is in the dormant section now:
> > >
> > >
> > >
> http://svn.apache.org/viewvc/commons/dormant/el/trunk/http://svn.apache.org/viewvc/commons/dormant/el/
> > >
> > >
> > > Bruno
> > >
> > >
> > > On Saturday, 30 May 2020, 7:12:40 pm NZST, Xeno Amess <
> xenoam...@gmail.com>
> > > wrote:
> > >
> > >
> > >
> > >
> > >
> > > https://github.com/apache/commons-el  is an empty repo.
> > > And according to
> > > http://commons.apache.org/dormant/commons-el/source-repository.html
> > > I should be able to found it at http:
> > > //svn.apache.org/viewvc/commons/proper/el/trunk
> > > but actually returns 404.
> > > so, what happened? is it dropped?
> > >
> > > -
> > > 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
>
>

[commons-lang] last commit fails checkstyle, thus fails travis-ci

[Xeno Amess]

Commit at :
https://github.com/apache/commons-lang/commit/c141bc961cb5cb84c47a21c3a5b0f15ab0035728
Don't worry, I've already being fixing it.
I will start a pr when things ready.

[bean-utils] MethodUtils.getPrimitiveWrapper : should we consider about Void and void?

[Xeno Amess]

right now the logic is :

/**
 * Gets the wrapper object class for the given primitive type class.
 * For example, passing {@code boolean.class returns Boolean.class}
 * @param primitiveType the primitive type class for which a match is
to be found
 * @return the wrapper type associated with the given primitive
 * or null if no match is found
 */
public static Class getPrimitiveWrapper(final Class primitiveType) {
// does anyone know a better strategy than comparing names?
if (boolean.class.equals(primitiveType)) {
return Boolean.class;
} else if (float.class.equals(primitiveType)) {
return Float.class;
} else if (long.class.equals(primitiveType)) {
return Long.class;
} else if (int.class.equals(primitiveType)) {
return Integer.class;
} else if (short.class.equals(primitiveType)) {
return Short.class;
} else if (byte.class.equals(primitiveType)) {
return Byte.class;
} else if (double.class.equals(primitiveType)) {
return Double.class;
} else if (char.class.equals(primitiveType)) {
return Character.class;
} else {

return null;
}
}

I know void can never be a class of a parameter of a function, but should
we consider about adding logics for void and Void?
after all void.class.isPrimitive() is true...

same question with function getPrimitiveType

Re: [Graph] moving to git

[Xeno Amess]

 >Github will be better to attract more contributors and easy to review codes
via PR

Just make sure to have enough reviews for reviewing prs.
IMO after put it to github you might receive far more prs than before.

Re: [Graph] moving to git

[Xeno Amess]

+1 in principle too.

Bruno P. Kinoshita  于2020年6月2日周二 上午11:24写道：

> I **think** projects using Apache gitbox can be/are hosted/mirrored on
> GitHub.
>
> As for moving to git, I'm +1 in principle. But I don't know if we create
> git repositories under github.com/apache for projects in the sandbox.
> Maybe one option here would be moving the sandbox over to git instead?
> Along with all the components there?
>
> Sorry if not very helpful.
>
> Bruno
>
>
> On Tuesday, 2 June 2020, 1:30:06 pm NZST, Amey Jadiye <
> ameyjad...@gmail.com> wrote:
>
>
>
>
>
> Hello All,
>
> I wanted to fetch opinion about moving commons-graph to git and possibly
> creation of github mirror.
>
> 1. Moving to git will be better for code management and change /
> contribution history perspective.
>
> 2. Github will be better to attract more contributors and easy to review
> codes via PR, not sure if Apache gitbox have same capabilities ?
>
> Regards,
> Amey Jadiye
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[lang] do anybody have some time to check my prs?

[Xeno Amess]

would be very glad if there be some guy giving some suggestions.

*performance improvement prs:*
[lang-1548]
split CharSequenceUtils.regionMatches() to two functions to improve 25%
performances.
also want to split related functons in StringUtils, but stucked here.
[lang-1549]
cleanroom implement CharSequenceUtils .lastIndexOf.
I do think the performance will increase in general, but it highly depends
on use data.
So I have no idea how to do the perform test.
As I also want to implement indexOf using same way, I need some help to
make sure the current version of the function can work.

*some other boring prs:*
[email-192]
[lang-1547]

Re: [Math] PR #143

[Xeno Amess]

Yes you are right.
>you must squash the commits.
>the commit messages are uninformative

Usually I'd do them when commiter think this pr is ok, and then tell me we
should merge it, and at that moment I squash it, and it get merged.
the commit messages will be fixed at that time too.

>partly revert a previous change

Yes, as my newest performance test shows something is not quite right in
my  previous changes. It makes the codes even slower.
So I changed that part.

>benchmark are indeed necessary

agreed, I did a benchmark yesterday, and pointed a link on github pages.
I'll copy/paste

>The PR contains different types of changes: one is "use arraycopy" but the
others are not documented anywhere (commit message, JIRA).
Ah, I forgot to create a jira ticket for it. sorry about that.

So, in conclusion, I will close this pr, and make two jira tickets, for the
two different types of refines.

Thanks for your help.

Gilles Sadowski  于2020年6月6日周六 下午7:33写道：

> Hi.
>
> 2020-06-06 10:18 UTC+02:00, GitBox :
> >
> > XenoAmess opened a new pull request #143:
> > URL: https://github.com/apache/commons-math/pull/143
> >
> >
> >use System.arraycopy instead of loop.
> >
>
> There are several issues with this PR.
>
> It contains several commits, among which some seem,
> IIUC, to partly revert a previous change in that same PR.
> It that situation, you must squash the commits (so that
> the net changes stand out).
> Also, the commit messages are uninformative ("refine",
> "fix false positive").
> The PR contains different types of changes: one is "use
> arraycopy" but the others are not documented anywhere
> (commit message, JIRA).
> Traceability and easy reviewing are requirements for
> "Commons" components.
> For example, modifying the code that fills an array is
> not a "minor" change, even if just because it makes the
> reviewer wonder "Why?" (and the answer is nowhere to
> be found from the official tracking tools).
> If some performance improvement is unexpected from
> looking at the code change, benchmark are indeed
> necessary especially if the new code is less clear (and
> a summary of the results should certainly make it into
> the commit message and/or the corresponding JIRA
> report).  [Also, an appropriately named utility method
> is probably better than inline statements.]
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] PR #143

[Xeno Amess]

Alright, done.
This pr is now splitted into two prs.
https://github.com/apache/commons-math/pull/144
https://github.com/apache/commons-math/pull/143

  Thx.

Xeno Amess  于2020年6月6日周六 下午7:47写道：

> Yes you are right.
> >you must squash the commits.
> >the commit messages are uninformative
>
> Usually I'd do them when commiter think this pr is ok, and then tell me we
> should merge it, and at that moment I squash it, and it get merged.
> the commit messages will be fixed at that time too.
>
> >partly revert a previous change
>
> Yes, as my newest performance test shows something is not quite right in
> my  previous changes. It makes the codes even slower.
> So I changed that part.
>
> >benchmark are indeed necessary
>
> agreed, I did a benchmark yesterday, and pointed a link on github pages.
> I'll copy/paste
>
> >The PR contains different types of changes: one is "use arraycopy" but
> the others are not documented anywhere (commit message, JIRA).
> Ah, I forgot to create a jira ticket for it. sorry about that.
>
> So, in conclusion, I will close this pr, and make two jira tickets, for
> the two different types of refines.
>
> Thanks for your help.
>
> Gilles Sadowski  于2020年6月6日周六 下午7:33写道：
>
>> Hi.
>>
>> 2020-06-06 10:18 UTC+02:00, GitBox :
>> >
>> > XenoAmess opened a new pull request #143:
>> > URL: https://github.com/apache/commons-math/pull/143
>> >
>> >
>> >use System.arraycopy instead of loop.
>> >
>>
>> There are several issues with this PR.
>>
>> It contains several commits, among which some seem,
>> IIUC, to partly revert a previous change in that same PR.
>> It that situation, you must squash the commits (so that
>> the net changes stand out).
>> Also, the commit messages are uninformative ("refine",
>> "fix false positive").
>> The PR contains different types of changes: one is "use
>> arraycopy" but the others are not documented anywhere
>> (commit message, JIRA).
>> Traceability and easy reviewing are requirements for
>> "Commons" components.
>> For example, modifying the code that fills an array is
>> not a "minor" change, even if just because it makes the
>> reviewer wonder "Why?" (and the answer is nowhere to
>> be found from the official tracking tools).
>> If some performance improvement is unexpected from
>> looking at the code change, benchmark are indeed
>> necessary especially if the new code is less clear (and
>> a summary of the results should certainly make it into
>> the commit message and/or the corresponding JIRA
>> report).  [Also, an appropriately named utility method
>> is probably better than inline statements.]
>>
>> Regards,
>> Gilles
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [VOTE] Release Apache Commons BCEL 6.5.0 based on RC1

[Xeno Amess]

+0

@garydgregory 

   1. should we change commons-parent directly, thus we do not need to
   change every repo's pom.xml?
   2. I see you add that plugin in  in this repo's pom.xml. Is it
   really needed? can we simply add/change ${commons.felix.version} and
   ${biz.aQute.bndlib.version} into  to make a samila effect?


Gary Gregory  于2020年6月6日周六 下午8:34写道：

> We have fixed a few bugs and added some enhancements since Apache Commons
> BCEL 6.4.1 was released, so I would like to release Apache Commons BCEL
> 6.5.0.
>
> Apache Commons BCEL 6.5.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1 (svn
> revision 39954)
>
> The Git tag commons-bcel-6.5.0-RC1 commit for this RC is
> a9c13ede0e565fae0593c1fde3b774d93abf3f71 which you can browse here:
>
>
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=a9c13ede0e565fae0593c1fde3b774d93abf3f71
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> --branch
> commons-bcel-6.5.0-RC1 commons-bcel-6.5.0-RC1
>
> Maven artifacts are here:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1499/org/apache/bcel/bcel/6.5.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Jun 05 17:50:12 EDT 2020
>
> bcel-6.5.0-bin.tar.gz=a97eb0b8c39ec96cf15168cc38d51065d4c3223729069bdf86ace61970124d73cee4b5ccfae605d0184c3154247abd382fc59241cecafb678532237167631212
>
> bcel-6.5.0-bin.zip=683f89e3c365d95882ca6d4d68408f578f25a5f5fda5af732cab175b29558b8d8c0a97aaa7d3026ba645d54160095dcda048ee12232f5a3f03e1293dd6621f20
>
> bcel-6.5.0-javadoc.jar=c82e46d666b04035b313ccf99e2e513bd02740c1c90d5cf0e02e00b819382525a1a793da72f3519a706ea189d5b163c72cf4d4a2feed6b74a47d756a912e905d
>
> bcel-6.5.0-sources.jar=2917b32067cd8c76b1691df8e882cf10be0fe6328e366c0d335e0f5e85d861a612577b1d9fbb2e6980a8fceb618f80abf8c1c80aa350c9e4a7166d4c2fb056dd
>
> bcel-6.5.0-src.tar.gz=c6da4b4d4cbad3ad2b3a4c0208063e3858170356fc4f6670c95ce819f0aea69f103914875a12bf2715a869c2b19a3e79fcb55a695eb269d9937520db25da1e3d
>
> bcel-6.5.0-src.zip=45642eb5e93da9da7252f17a0e58ee17c952b569e86d398353daa2a0bf4846a34ea79acd3329fa317814e15706e9993d4529c217476734918b97e1adb2ea7773
>
> bcel-6.5.0-test-sources.jar=aed90e44f7e49e2ea39e945a55aa2bf28b7c87685afea0c68d3e83f1acb5488290d70d2b18f62a89bf31509f226ee3c46811e608b7bca447edeceb83bdee3a4d
>
> bcel-6.5.0-tests.jar=2b7dfef01c8f885e351590267c5236c6512658ddb70ab80ca1fb5b9035e4176a410f76dc22199959a2343c03917fc30d1fe6d35715cc3bae550a8021f0ea7e57
>
> I have tested this with 'mvn -V -Duser.name=%my_apache_id%
> -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease
> -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Java\apache-maven-3.6.3\bin\..
> Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_251\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Details of changes since 6.4.1 are in the release notes:
>
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/RELEASE-NOTES.txt
>
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/changes-report.html
>
> Site:
>
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/index.html
> (note some *relative* links are broken and the 6.5.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 6.4.1):
>
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/japicmp.html
>
> RAT Report:
>
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> commons-bcel-6.5.0-RC1 commons-bcel-6.5.0-RC1
> cd commons-bcel-6.5.0-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site incl

Re: [VOTE] Release Apache Commons BCEL 6.5.0 based on RC1

[Xeno Amess]

>it seems you are talking about moving some dependency management from this
component to the
parent POM.

Yes, I'm talking about this part in bcel's pom.xml,
  
org.apache.felix
maven-bundle-plugin

  
biz.aQute.bnd
biz.aQute.bndlib
5.1.0
  

  
>This should not hold up the release

Agreed, as it does not really influnce the binary/jar built output. So I
put a +0 here just for reminder, but not a -0.

Gary Gregory  于2020年6月6日周六 下午10:31写道：

> I am not sure what this has to do with the release, it seems you are
> talking about moving some dependency management from this component to the
> parent POM. This should not hold up the release unless I am missing
> something.
>
> Gary
>
> On Sat, Jun 6, 2020, 08:37 Xeno Amess  wrote:
>
> > +0
> >
> > @garydgregory <https://github.com/garydgregory>
> >
> >1. should we change commons-parent directly, thus we do not need to
> >change every repo's pom.xml?
> >2. I see you add that plugin in  in this repo's pom.xml. Is it
> >really needed? can we simply add/change ${commons.felix.version} and
> >${biz.aQute.bndlib.version} into  to make a samila effect?
> >
> >
> > Gary Gregory  于2020年6月6日周六 下午8:34写道：
> >
> > > We have fixed a few bugs and added some enhancements since Apache
> Commons
> > > BCEL 6.4.1 was released, so I would like to release Apache Commons BCEL
> > > 6.5.0.
> > >
> > > Apache Commons BCEL 6.5.0 RC1 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1 (svn
> > > revision 39954)
> > >
> > > The Git tag commons-bcel-6.5.0-RC1 commit for this RC is
> > > a9c13ede0e565fae0593c1fde3b774d93abf3f71 which you can browse here:
> > >
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=a9c13ede0e565fae0593c1fde3b774d93abf3f71
> > > You may checkout this tag using:
> > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > > --branch
> > > commons-bcel-6.5.0-RC1 commons-bcel-6.5.0-RC1
> > >
> > > Maven artifacts are here:
> > >
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1499/org/apache/bcel/bcel/6.5.0/
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Fri Jun 05 17:50:12 EDT 2020
> > >
> > >
> >
> bcel-6.5.0-bin.tar.gz=a97eb0b8c39ec96cf15168cc38d51065d4c3223729069bdf86ace61970124d73cee4b5ccfae605d0184c3154247abd382fc59241cecafb678532237167631212
> > >
> > >
> >
> bcel-6.5.0-bin.zip=683f89e3c365d95882ca6d4d68408f578f25a5f5fda5af732cab175b29558b8d8c0a97aaa7d3026ba645d54160095dcda048ee12232f5a3f03e1293dd6621f20
> > >
> > >
> >
> bcel-6.5.0-javadoc.jar=c82e46d666b04035b313ccf99e2e513bd02740c1c90d5cf0e02e00b819382525a1a793da72f3519a706ea189d5b163c72cf4d4a2feed6b74a47d756a912e905d
> > >
> > >
> >
> bcel-6.5.0-sources.jar=2917b32067cd8c76b1691df8e882cf10be0fe6328e366c0d335e0f5e85d861a612577b1d9fbb2e6980a8fceb618f80abf8c1c80aa350c9e4a7166d4c2fb056dd
> > >
> > >
> >
> bcel-6.5.0-src.tar.gz=c6da4b4d4cbad3ad2b3a4c0208063e3858170356fc4f6670c95ce819f0aea69f103914875a12bf2715a869c2b19a3e79fcb55a695eb269d9937520db25da1e3d
> > >
> > >
> >
> bcel-6.5.0-src.zip=45642eb5e93da9da7252f17a0e58ee17c952b569e86d398353daa2a0bf4846a34ea79acd3329fa317814e15706e9993d4529c217476734918b97e1adb2ea7773
> > >
> > >
> >
> bcel-6.5.0-test-sources.jar=aed90e44f7e49e2ea39e945a55aa2bf28b7c87685afea0c68d3e83f1acb5488290d70d2b18f62a89bf31509f226ee3c46811e608b7bca447edeceb83bdee3a4d
> > >
> > >
> >
> bcel-6.5.0-tests.jar=2b7dfef01c8f885e351590267c5236c6512658ddb70ab80ca1fb5b9035e4176a410f76dc22199959a2343c03917fc30d1fe6d35715cc3bae550a8021f0ea7e57
> > >
> > > I have tested this with 'mvn -V -Duser.name=%my_apache_id%
> > > -Dcommons.release-plugin.version=%commons.release-plugin.version%
> > -Prelease
> > > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> > >
> > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > > Maven home: C:\Java\apache-maven-3.6.3\bin\..
> > > Java version: 1.8.0_251, vendor: Oracle Corporation, runtime:
> C:\Program
> > > Files\Java\jdk1.8.0_251\jre
> > > Default locale: en_US, platform encoding: Cp1252
> > > OS name: "windows 

Re: [Math] PR #143

[Xeno Amess]

If you are telling about 144:
yes, original codes runs like:
f[0] = f0;
f[1] = f1;
f[2] = f[2-2] = f[0] = f[0]
f[3] = f[3-2] = f[1] = f[1]
f[4] = f[4-2] = f[2] = f[0]
f[5] = f[5-2] = f[3] = f[1]

the new codes runs like:
f[0] = f0;
f[1] = f1;
f[2] = 2&1==0 ? f0 : f1 = f0
f[3] = 3&1==0 ? f0 : f1 = f1
f[4] = 4&1==0 ? f0 : f1 = f0
f[5] = 5&1==0 ? f0 : f1 = f1

thus it runs faster for around 7% faster on my performance tests.




Gilles Sadowski  于2020年6月7日周日 上午5:53写道：

> Hi.
>
> 2020-06-06 14:21 UTC+02:00, Xeno Amess :
> > Alright, done.
> > This pr is now splitted into two prs.
> > https://github.com/apache/commons-math/pull/144
> > https://github.com/apache/commons-math/pull/143
>
> I think that there are issues with some of the changes (e.g. where
> the previous code used an "index" variable but in the new version
> there is a hard-coded number).
>
> Gilles
>
> > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] PR #143

[Xeno Amess]

Ahhh you are right.
I'm new to JIRA. sory

Gilles Sadowski  于2020年6月7日周日 下午6:50写道：

> Hi.
>
> 2020-06-07 8:21 UTC+02:00, Xeno Amess :
> > If you are telling about 144:
> > yes, original codes runs like:
> > f[0] = f0;
> > f[1] = f1;
> > f[2] = f[2-2] = f[0] = f[0]
> > f[3] = f[3-2] = f[1] = f[1]
> > f[4] = f[4-2] = f[2] = f[0]
> > f[5] = f[5-2] = f[3] = f[1]
> >
> > the new codes runs like:
> > f[0] = f0;
> > f[1] = f1;
> > f[2] = 2&1==0 ? f0 : f1 = f0
> > f[3] = 3&1==0 ? f0 : f1 = f1
> > f[4] = 4&1==0 ? f0 : f1 = f0
> > f[5] = 5&1==0 ? f0 : f1 = f1
> >
> > thus it runs faster for around 7% faster on my performance tests.
> >
>
> Wrong thread.
> Please reply on JIRA, where this discussion should be taking place.[1]
>
> Regards,
> Gilles
>
> [1] https://issues.apache.org/jira/browse/MATH-1538
>
> >
> >
> > Gilles Sadowski  于2020年6月7日周日 上午5:53写道：
> >
> >> Hi.
> >>
> >> 2020-06-06 14:21 UTC+02:00, Xeno Amess :
> >> > Alright, done.
> >> > This pr is now splitted into two prs.
> >> > https://github.com/apache/commons-math/pull/144
> >> > https://github.com/apache/commons-math/pull/143
> >>
> >> I think that there are issues with some of the changes (e.g. where
> >> the previous code used an "index" variable but in the new version
> >> there is a hard-coded number).
> >>
> >> Gilles
> >>
> >> > [...]
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-graph] branch master updated: Travis CI configuration.

[Xeno Amess]

Hi.
I see the current travis-ci scripts.
Do we really care only jdk8?
Should we also add at some other jdk versions, at least adding openjdk11,
as it is a stable version?
Or this repo has some known bug on jdk11?

some questions about commons projects.

[Xeno Amess]

1. How can a project *** becomes commons-***, or how did a commons-***
project started? What is the actual procedural?
2. How are commons projects related? Are they under a same (or at least
similar) management mechanism? Or just sharing a common prefix?
3. How is commons projects' version control, based on function or based on
time?
4. Why some projects are on svn, some on gitbox, and some on github?
5. What problems shall be put on mailing list, and what problems shall be
put on Jira?
6. Is there quite some dead projects in commons? And how to detect/mark
them?
7. What is the general waiting time for a pr to be reviewed(and rejected or
accepted)? In my own observation the waiting time is between [1 days, 1.5
years) , is it a little...large?
8. What should we do when we have a pr delayed for a long time? And how
long is thought to be an unusual long time for waiting? 3 days.1 week,or 1
month?

Sorry for having so many questions, but I'm just very curious.

Re: some questions about commons projects.

[Xeno Amess]

Hi.

>> 2. How are commons projects related?

> They are not necessarily related.  Usually it is considered
> a feature if a component has zero dependency (as it is was
> easier to avoid "JAR hell").
> However, there are also drawbacks, e.g. duplicating functionality
> (and work) needed by several components.

Something was not quite right about this.
For example, in commons-vfs, we just use commons-lang3 as a dependency.
But in commons-email, we fork some of utility functions in commons-lang3 as
a java class in commons-email.
Which is the right way, or a more commonly accepted way in commons projects?


Gilles Sadowski  于2020年6月12日周五 下午9:07写道：

> Hello.
>
> Le ven. 12 juin 2020 à 13:51, Xeno Amess  a écrit :
> >
> > 1. How can a project *** becomes commons-***, or how did a commons-***
> > project started? What is the actual procedural?
>
> For new components, this list would be the place to make the
> proposal.  A discussion would decide if "Apache Commons" is
> the right place (given the interest/capacity of the current team).
>
> > 2. How are commons projects related?
>
> They are not necessarily related.  Usually it is considered
> a feature if a component has zero dependency (as it is was
> easier to avoid "JAR hell").
> However, there are also drawbacks, e.g. duplicating functionality
> (and work) needed by several components.
>
> > Are they under a same (or at least
> > similar) management mechanism? Or just sharing a common prefix?
>
> Do you mean the development tools (maven, git)?
> There some measure of "standardization" through the parent POM
> file, but nothing is really enforced.  The code style depends on the
> regular contributors (and how old the codebase was when it was
> considered "mature").
>
> > 3. How is commons projects' version control, based on function or based
> on
> > time?
>
> A backward-compatible release has its minor version number
> increased; otherwise both the major number and the base package
> are changed.
>
> > 4. Why some projects are on svn, some on gitbox, and some on github?
>
> All actively developed components were (will be) moved to "gitbox"
> (decision made a few years ago, cf. "dev" M archive).
> Those remaining on SVN are probably mainly "dormant" (except
> perhaps for some security fix).
>
> IIUC, a "GitHub" mirror is automatically created for every new
> "gitbox" Apache project.
>
> > 5. What problems shall be put on mailing list, and what problems shall be
> > put on Jira?
>
> ML: proposal, discussion on design, ...
> JIRA: identified bugs (with references and/or unit test), accepted
> feature, discussion on implementation details, ...
>
> > 6. Is there quite some dead projects in commons? And how to detect/mark
> > them?
>
> Depends on the definition of "dead".
> None of the components in "proper" are considered dead, even if
> they are not actively developed anymore (whether this is "good"
> or "bad" is another question).
> I haven't seen anything in "sandbox" being developed for a long
> time (until the last few days where "Commons Graph" seems it
> may be revived).
> Unless I'm mistaken, a project in "dormant" has been subject to
> decision for stopping its development.
>
> > 7. What is the general waiting time for a pr to be reviewed(and rejected
> or
> > accepted)? In my own observation the waiting time is between [1 days, 1.5
> > years) , is it a little...large?
>
> It boils down to the level of involvement of a committer for the
> component being the target of the PR.
> Developers being volunteers, it certainly also depends on the
> balance between the usefulness of the PR and the work required
> from the reviewer.
>
> > 8. What should we do when we have a pr delayed for a long time? And how
> > long is thought to be an unusual long time for waiting? 3 days.1 week,or
> 1
> > month?
>
> They might have been forgotten, or there may other issues.
> Examples?
>
> >
> > Sorry for having so many questions, but I'm just very curious.
>
> Hope the above answers have helped.
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: some questions about commons projects.

[Xeno Amess]

>> Are they under a same (or at least
>> similar) management mechanism? Or just sharing a common prefix?

> Do you mean the development tools (maven, git)?
> There some measure of "standardization" through the parent POM
> file, but nothing is really enforced.  The code style depends on the
> regular contributors (and how old the codebase was when it was
> considered "mature").

So...if we treat a repo as a city, there should be some regular
contributors like Mayor or something, and PMCs are more like Special Envoy
from the King, correct?
And in usual cases the "some regular contributors" are people who review
prs.
But what will happen if the "some regular contributors" all become busy and
nobody be willing to review?
Is there a mechanism for this situation?

Xeno Amess  于2020年6月12日周五 下午9:29写道：

> Hi.
>
> >> 2. How are commons projects related?
>
> > They are not necessarily related.  Usually it is considered
> > a feature if a component has zero dependency (as it is was
> > easier to avoid "JAR hell").
> > However, there are also drawbacks, e.g. duplicating functionality
> > (and work) needed by several components.
>
> Something was not quite right about this.
> For example, in commons-vfs, we just use commons-lang3 as a dependency.
> But in commons-email, we fork some of utility functions in commons-lang3
> as a java class in commons-email.
> Which is the right way, or a more commonly accepted way in commons
> projects?
>
>
> Gilles Sadowski  于2020年6月12日周五 下午9:07写道：
>
>> Hello.
>>
>> Le ven. 12 juin 2020 à 13:51, Xeno Amess  a écrit :
>> >
>> > 1. How can a project *** becomes commons-***, or how did a commons-***
>> > project started? What is the actual procedural?
>>
>> For new components, this list would be the place to make the
>> proposal.  A discussion would decide if "Apache Commons" is
>> the right place (given the interest/capacity of the current team).
>>
>> > 2. How are commons projects related?
>>
>> They are not necessarily related.  Usually it is considered
>> a feature if a component has zero dependency (as it is was
>> easier to avoid "JAR hell").
>> However, there are also drawbacks, e.g. duplicating functionality
>> (and work) needed by several components.
>>
>> > Are they under a same (or at least
>> > similar) management mechanism? Or just sharing a common prefix?
>>
>> Do you mean the development tools (maven, git)?
>> There some measure of "standardization" through the parent POM
>> file, but nothing is really enforced.  The code style depends on the
>> regular contributors (and how old the codebase was when it was
>> considered "mature").
>>
>> > 3. How is commons projects' version control, based on function or based
>> on
>> > time?
>>
>> A backward-compatible release has its minor version number
>> increased; otherwise both the major number and the base package
>> are changed.
>>
>> > 4. Why some projects are on svn, some on gitbox, and some on github?
>>
>> All actively developed components were (will be) moved to "gitbox"
>> (decision made a few years ago, cf. "dev" M archive).
>> Those remaining on SVN are probably mainly "dormant" (except
>> perhaps for some security fix).
>>
>> IIUC, a "GitHub" mirror is automatically created for every new
>> "gitbox" Apache project.
>>
>> > 5. What problems shall be put on mailing list, and what problems shall
>> be
>> > put on Jira?
>>
>> ML: proposal, discussion on design, ...
>> JIRA: identified bugs (with references and/or unit test), accepted
>> feature, discussion on implementation details, ...
>>
>> > 6. Is there quite some dead projects in commons? And how to detect/mark
>> > them?
>>
>> Depends on the definition of "dead".
>> None of the components in "proper" are considered dead, even if
>> they are not actively developed anymore (whether this is "good"
>> or "bad" is another question).
>> I haven't seen anything in "sandbox" being developed for a long
>> time (until the last few days where "Commons Graph" seems it
>> may be revived).
>> Unless I'm mistaken, a project in "dormant" has been subject to
>> decision for stopping its development.
>>
>> > 7. What is the general waiting time for a pr to be reviewed(and
>> rej

Re: some questions about commons projects.

[Xeno Amess]

>> 8. What should we do when we have a pr delayed for a long time? And how
>> long is thought to be an unusual long time for waiting? 3 days.1 week,or
1
>> month?

> They might have been forgotten, or there may other issues.
> Examples?

for 1 year example:
https://github.com/apache/commons-lang/pull/428
for half year example:
https://github.com/apache/commons-vfs/pull/78
(I have no idea whether it is already resolved, as I have not received any
report about it being resolved, and the pr is still not closed or marked
resolved by someone.)
for two weeks example:
too many.
As I said above, I have no better way for detecting whether a repo is
"active", so I send some "trying minor prs" to every repo (nearly).
Most of them have no response.
No approving, no rejection, no modification suggestions.
If you really wanna details, I will try to make a list for you.


Xeno Amess  于2020年6月12日周五 下午9:36写道：

> >> Are they under a same (or at least
> >> similar) management mechanism? Or just sharing a common prefix?
>
> > Do you mean the development tools (maven, git)?
> > There some measure of "standardization" through the parent POM
> > file, but nothing is really enforced.  The code style depends on the
> > regular contributors (and how old the codebase was when it was
> > considered "mature").
>
> So...if we treat a repo as a city, there should be some regular
> contributors like Mayor or something, and PMCs are more like Special Envoy
> from the King, correct?
> And in usual cases the "some regular contributors" are people who review
> prs.
> But what will happen if the "some regular contributors" all become busy
> and nobody be willing to review?
> Is there a mechanism for this situation?
>
> Xeno Amess  于2020年6月12日周五 下午9:29写道：
>
>> Hi.
>>
>> >> 2. How are commons projects related?
>>
>> > They are not necessarily related.  Usually it is considered
>> > a feature if a component has zero dependency (as it is was
>> > easier to avoid "JAR hell").
>> > However, there are also drawbacks, e.g. duplicating functionality
>> > (and work) needed by several components.
>>
>> Something was not quite right about this.
>> For example, in commons-vfs, we just use commons-lang3 as a dependency.
>> But in commons-email, we fork some of utility functions in commons-lang3
>> as a java class in commons-email.
>> Which is the right way, or a more commonly accepted way in commons
>> projects?
>>
>>
>> Gilles Sadowski  于2020年6月12日周五 下午9:07写道：
>>
>>> Hello.
>>>
>>> Le ven. 12 juin 2020 à 13:51, Xeno Amess  a écrit :
>>> >
>>> > 1. How can a project *** becomes commons-***, or how did a commons-***
>>> > project started? What is the actual procedural?
>>>
>>> For new components, this list would be the place to make the
>>> proposal.  A discussion would decide if "Apache Commons" is
>>> the right place (given the interest/capacity of the current team).
>>>
>>> > 2. How are commons projects related?
>>>
>>> They are not necessarily related.  Usually it is considered
>>> a feature if a component has zero dependency (as it is was
>>> easier to avoid "JAR hell").
>>> However, there are also drawbacks, e.g. duplicating functionality
>>> (and work) needed by several components.
>>>
>>> > Are they under a same (or at least
>>> > similar) management mechanism? Or just sharing a common prefix?
>>>
>>> Do you mean the development tools (maven, git)?
>>> There some measure of "standardization" through the parent POM
>>> file, but nothing is really enforced.  The code style depends on the
>>> regular contributors (and how old the codebase was when it was
>>> considered "mature").
>>>
>>> > 3. How is commons projects' version control, based on function or
>>> based on
>>> > time?
>>>
>>> A backward-compatible release has its minor version number
>>> increased; otherwise both the major number and the base package
>>> are changed.
>>>
>>> > 4. Why some projects are on svn, some on gitbox, and some on github?
>>>
>>> All actively developed components were (will be) moved to "gitbox"
>>> (decision made a few years ago, cf. "dev" M archive).
>>> Those remaining on SVN are probably mainly "dormant" (except
>>> perhaps for some security fix).
>>>
>>> IIU

Re: some questions about commons projects.

[Xeno Amess]

> Some terms:
> - Apache Commons is an Apache _project_.
> - Apache Commons Lang is a _component_ of the _project_.

> Each component has its own level of functionality and granularity. Some
are
> lower level, like Commons Lang and Commons IO and do not depend on
anything
> at runtime.
> Others offer higher levels of functionality like Commons VFS, Commons
> Configuration, Commons Digester, and Commons Weaver.
> You'll notice that some of the lower-level components offer a single Maven
> module and jar, while others offer many.
> There is no uniform granularity to be expected.

Get it, at least, kind of.
But if Apache Commons is thought to be a whole project, I do think the
relationship between each of its components should be enforced.
For example, we might start from trying to use a same code style formatter.
Thanks.

Gary Gregory  于2020年6月12日周五 下午9:42写道：

> On Fri, Jun 12, 2020 at 9:30 AM Xeno Amess  wrote:
>
> > Hi.
> >
> > >> 2. How are commons projects related?
> >
> > > They are not necessarily related.  Usually it is considered
> > > a feature if a component has zero dependency (as it is was
> > > easier to avoid "JAR hell").
> > > However, there are also drawbacks, e.g. duplicating functionality
> > > (and work) needed by several components.
> >
> > Something was not quite right about this.
> > For example, in commons-vfs, we just use commons-lang3 as a dependency.
> > But in commons-email, we fork some of utility functions in commons-lang3
> as
> > a java class in commons-email.
> > Which is the right way, or a more commonly accepted way in commons
> > projects?
> >
>
> Some terms:
> - Apache Commons is an Apache _project_.
> - Apache Commons Lang is a _component_ of the _project_.
>
> Each component has its own level of functionality and granularity. Some are
> lower level, like Commons Lang and Commons IO and do not depend on anything
> at runtime.
> Others offer higher levels of functionality like Commons VFS, Commons
> Configuration, Commons Digester, and Commons Weaver.
> You'll notice that some of the lower-level components offer a single Maven
> module and jar, while others offer many.
> There is no uniform granularity to be expected.
>
> HTH,
> Gary
>
>
> >
> > Gilles Sadowski  于2020年6月12日周五 下午9:07写道：
> >
> > > Hello.
> > >
> > > Le ven. 12 juin 2020 à 13:51, Xeno Amess  a
> écrit :
> > > >
> > > > 1. How can a project *** becomes commons-***, or how did a
> commons-***
> > > > project started? What is the actual procedural?
> > >
> > > For new components, this list would be the place to make the
> > > proposal.  A discussion would decide if "Apache Commons" is
> > > the right place (given the interest/capacity of the current team).
> > >
> > > > 2. How are commons projects related?
> > >
> > > They are not necessarily related.  Usually it is considered
> > > a feature if a component has zero dependency (as it is was
> > > easier to avoid "JAR hell").
> > > However, there are also drawbacks, e.g. duplicating functionality
> > > (and work) needed by several components.
> > >
> > > > Are they under a same (or at least
> > > > similar) management mechanism? Or just sharing a common prefix?
> > >
> > > Do you mean the development tools (maven, git)?
> > > There some measure of "standardization" through the parent POM
> > > file, but nothing is really enforced.  The code style depends on the
> > > regular contributors (and how old the codebase was when it was
> > > considered "mature").
> > >
> > > > 3. How is commons projects' version control, based on function or
> based
> > > on
> > > > time?
> > >
> > > A backward-compatible release has its minor version number
> > > increased; otherwise both the major number and the base package
> > > are changed.
> > >
> > > > 4. Why some projects are on svn, some on gitbox, and some on github?
> > >
> > > All actively developed components were (will be) moved to "gitbox"
> > > (decision made a few years ago, cf. "dev" M archive).
> > > Those remaining on SVN are probably mainly "dormant" (except
> > > perhaps for some security fix).
> > >
> > > IIUC, a "GitHub" mirror is automatically created for every new
> > > "gitbox" Apache project.
> > >
> > > &

Re: some questions about commons projects.

[Xeno Amess]

> Hopefully we mean the same thing, but this is not
> true: Only those components for which a git repository
> was set up have their SVN set as read-only (by INFRA).

> See also my recent post asking how to finalize the
> move (to the "read-only area") of [Graph].

And maybe this is kind of off topic, but I once saw some svn links in some
of the repos' pages, and be ineffective, last month.
And I don't know whether it happened in other repos.

Gilles Sadowski  于2020年6月12日周五 下午9:50写道：

> 2020-06-12 15:36 UTC+02:00, Gary Gregory :
> > On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski 
> > wrote:
> >
> >> Hello.
> >>
> >> Le ven. 12 juin 2020 à 13:51, Xeno Amess  a écrit
> :
> >> >
> >> > 1. How can a project *** becomes commons-***, or how did a commons-***
> >> > project started? What is the actual procedural?
> >>
> >> For new components, this list would be the place to make the
> >> proposal.  A discussion would decide if "Apache Commons" is
> >> the right place (given the interest/capacity of the current team).
> >>
> >> > 2. How are commons projects related?
> >>
> >> They are not necessarily related.  Usually it is considered
> >> a feature if a component has zero dependency (as it is was
> >> easier to avoid "JAR hell").
> >> However, there are also drawbacks, e.g. duplicating functionality
> >> (and work) needed by several components.
> >>
> >> > Are they under a same (or at least
> >> > similar) management mechanism? Or just sharing a common prefix?
> >>
> >> Do you mean the development tools (maven, git)?
> >> There some measure of "standardization" through the parent POM
> >> file, but nothing is really enforced.  The code style depends on the
> >> regular contributors (and how old the codebase was when it was
> >> considered "mature").
> >>
> >> > 3. How is commons projects' version control, based on function or
> based
> >> on
> >> > time?
> >>
> >> A backward-compatible release has its minor version number
> >> increased; otherwise both the major number and the base package
> >> are changed.
> >>
> >> > 4. Why some projects are on svn, some on gitbox, and some on github?
> >>
> >> All actively developed components were (will be) moved to "gitbox"
> >> (decision made a few years ago, cf. "dev" M archive).
> >> Those remaining on SVN are probably mainly "dormant" (except
> >> perhaps for some security fix).
> >>
> >
> > Not quite. SVN should be considered read-only. A new work should be done
> in
> > Git.
>
> Hopefully we mean the same thing, but this is not
> true: Only those components for which a git repository
> was set up have their SVN set as read-only (by INFRA).
>
> See also my recent post asking how to finalize the
> move (to the "read-only area") of [Graph].
>
> Regards,
> Gilles
>
> >
> > Gary
> >
> >
> >>
> >> IIUC, a "GitHub" mirror is automatically created for every new
> >> "gitbox" Apache project.
> >>
> >> > 5. What problems shall be put on mailing list, and what problems shall
> >> > be
> >> > put on Jira?
> >>
> >> ML: proposal, discussion on design, ...
> >> JIRA: identified bugs (with references and/or unit test), accepted
> >> feature, discussion on implementation details, ...
> >>
> >> > 6. Is there quite some dead projects in commons? And how to
> detect/mark
> >> > them?
> >>
> >> Depends on the definition of "dead".
> >> None of the components in "proper" are considered dead, even if
> >> they are not actively developed anymore (whether this is "good"
> >> or "bad" is another question).
> >> I haven't seen anything in "sandbox" being developed for a long
> >> time (until the last few days where "Commons Graph" seems it
> >> may be revived).
> >> Unless I'm mistaken, a project in "dormant" has been subject to
> >> decision for stopping its development.
> >>
> >> > 7. What is the general waiting time for a pr to be reviewed(and
> >> > rejected
> >> or
> >> > accepted)? In my own observation the waiting time is between [1 days,
> >> > 1.5
> >> >

Re: some questions about commons projects.

[Xeno Amess]

> Speaking for myself, as a volunteer here, I do what I can, when I can,
with
> a eye toward using my time wisely while balancing many other
> responsibilities.
> Commons has over 20 components, some I use at work, some I used at play,
> some I do not use.
> I do my best to pick low hanging fruits, fix bugs that could be
> troublesome, and implement new features I feel would clearly benefit a
> component's community, or that I simply need.
> All of this takes time; thow in this mailing list, JIRAs, PRs from GitHub,
> and that's a lot to chew on. IOW, be patient, manage your expectations
;-)
I never doubt this. I know you are busy and put a lot of effort on commons.
And your helps/suggestions are actually really helpful in most of
the times. Thank you.
I'm just, kind of curious about how things works here normally.
Thanks.

Gary Gregory  于2020年6月12日周五 下午9:56写道：

> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess  wrote:
>
> > >> 8. What should we do when we have a pr delayed for a long time? And
> how
> > >> long is thought to be an unusual long time for waiting? 3 days.1
> week,or
> > 1
> > >> month?
> >
> > > They might have been forgotten, or there may other issues.
> > > Examples?
> >
> > for 1 year example:
> > https://github.com/apache/commons-lang/pull/428
> > for half year example:
> > https://github.com/apache/commons-vfs/pull/78
> > (I have no idea whether it is already resolved, as I have not received
> any
> > report about it being resolved, and the pr is still not closed or marked
> > resolved by someone.)
> > for two weeks example:
> > too many.
> > As I said above, I have no better way for detecting whether a repo is
> > "active", so I send some "trying minor prs" to every repo (nearly).
> > Most of them have no response.
> > No approving, no rejection, no modification suggestions.
> > If you really wanna details, I will try to make a list for you.
> >
>
> Speaking for myself, as a volunteer here, I do what I can, when I can, with
> a eye toward using my time wisely while balancing many other
> responsibilities.
> Commons has over 20 components, some I use at work, some I used at play,
> some I do not use.
> I do my best to pick low hanging fruits, fix bugs that could be
> troublesome, and implement new features I feel would clearly benefit a
> component's community, or that I simply need.
> All of this takes time; thow in this mailing list, JIRAs, PRs from GitHub,
> and that's a lot to chew on. IOW, be patient, manage your expectations ;-)
>
> HTH,
> Gary
>
>
> >
> >
> > Xeno Amess  于2020年6月12日周五 下午9:36写道：
> >
> > > >> Are they under a same (or at least
> > > >> similar) management mechanism? Or just sharing a common prefix?
> > >
> > > > Do you mean the development tools (maven, git)?
> > > > There some measure of "standardization" through the parent POM
> > > > file, but nothing is really enforced.  The code style depends on the
> > > > regular contributors (and how old the codebase was when it was
> > > > considered "mature").
> > >
> > > So...if we treat a repo as a city, there should be some regular
> > > contributors like Mayor or something, and PMCs are more like Special
> > Envoy
> > > from the King, correct?
> > > And in usual cases the "some regular contributors" are people who
> review
> > > prs.
> > > But what will happen if the "some regular contributors" all become busy
> > > and nobody be willing to review?
> > > Is there a mechanism for this situation?
> > >
> > > Xeno Amess  于2020年6月12日周五 下午9:29写道：
> > >
> > >> Hi.
> > >>
> > >> >> 2. How are commons projects related?
> > >>
> > >> > They are not necessarily related.  Usually it is considered
> > >> > a feature if a component has zero dependency (as it is was
> > >> > easier to avoid "JAR hell").
> > >> > However, there are also drawbacks, e.g. duplicating functionality
> > >> > (and work) needed by several components.
> > >>
> > >> Something was not quite right about this.
> > >> For example, in commons-vfs, we just use commons-lang3 as a
> dependency.
> > >> But in commons-email, we fork some of utility functions in
> commons-lang3
> > >> as a java class in commons-email.
> > >> Which is the right way, or a more commonly accepted way in commons

Re: some questions about commons projects.

[Xeno Amess]

> Well, you had quite a few responses from me, for PRs
> pertaining to "Commons Math"
Indeed. And I think I learned a lot from you too. Thanks.

> even though that one I
> qualify as a "zombie" project!  [How it came to that
> state is told in the "dev" ML.]
Ah, I thought it be among the alive repos...
Sorry about that.

> help solving issues that would block the next release.
I'll try.

Now my workflow is like:

In playing/training mode:
1.detect which repo is active.
2.try to fix some minor things. (and kind of for debugging a toolchain
which I maintained.)
3.try to rewrite somethings for better performance. (then run jmh.)

In working mode:
1. met a bug when I use some of commons repos (Yep I am your loyal user).
2. try to locate the bug.
3. try to fix it and report.

I don't know whether it be a correct way, but I hope I will not make anyone
suffer.(or at least not that much suffer)
Sorry if I made any trouble.

Gilles Sadowski  于2020年6月12日周五 下午10:04写道：

> Hi.
>
> 2020-06-12 15:44 UTC+02:00, Xeno Amess :
> >>> 8. What should we do when we have a pr delayed for a long time? And how
> >>> long is thought to be an unusual long time for waiting? 3 days.1
> week,or
> > 1
> >>> month?
> >
> >> They might have been forgotten, or there may other issues.
> >> Examples?
> >
> > for 1 year example:
> > https://github.com/apache/commons-lang/pull/428
> > for half year example:
> > https://github.com/apache/commons-vfs/pull/78
> > (I have no idea whether it is already resolved, as I have not received
> any
> > report about it being resolved, and the pr is still not closed or marked
> > resolved by someone.)
>
> I can't really comment, as I seldom participate in
> changes to those components.
>
> > for two weeks example:
> > too many.
> > As I said above, I have no better way for detecting whether a repo is
> > "active", so I send some "trying minor prs" to every repo (nearly).
> > Most of them have no response.
>
> Well, you had quite a few responses from me, for PRs
> pertaining to "Commons Math" even though that one I
> qualify as a "zombie" project!  [How it came to that
> state is told in the "dev" ML.]
>
> > No approving, no rejection, no modification suggestions.
> > If you really wanna details, I will try to make a list for you.
>
> Just guessing, but perhaps the issue is the one I outlined
> in my previous reply (and on the JIRA report which you
> created ): There are many issues to work on, big to small
> down to nit-picks; but surely some have higher "added
> value".
> Personally I don't think that creating "nit-pick" PRs is the
> right way for querying the "liveness" of a project.  Better
> ask the question directly on the "dev" ML and/or raise and
> help solving issues that would block the next release.
>
> Regards,
> Gilles
>
> >>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: some questions about commons projects.

[Xeno Amess]

>> Speaking for myself, as a volunteer here, I do what I can, when I can,
with
>> a eye toward using my time wisely while balancing many other
>> responsibilities.
>> Commons has over 20 components, some I use at work, some I used at play,
>> some I do not use.
>> I do my best to pick low hanging fruits, fix bugs that could be
>> troublesome, and implement new features I feel would clearly benefit a
>> component's community, or that I simply need.
>> All of this takes time; thow in this mailing list, JIRAs, PRs from
GitHub,
>> and that's a lot to chew on. IOW, be patient, manage your expectations
;-)
> I never doubt this. I know you are busy and put a lot of effort on
commons. And your helps/suggestions are actually really helpful in most of
the times. Thank you.
> I'm just, kind of curious about how things works here normally.
> Thanks.
I have a strange feeling as most of my prs are reviewed by you, a PMC, but
not a normal committer.
Is it a normal state? Or what wrongs/mistakes did I make?
Because I think normal committers should be the group who review most of
the prs, and PMC committers shall struggle for some more important things,
maybe I mis-understand somethings(again)?

Xeno Amess  于2020年6月12日周五 下午10:01写道：

> > Speaking for myself, as a volunteer here, I do what I can, when I can,
> with
> > a eye toward using my time wisely while balancing many other
> > responsibilities.
> > Commons has over 20 components, some I use at work, some I used at play,
> > some I do not use.
> > I do my best to pick low hanging fruits, fix bugs that could be
> > troublesome, and implement new features I feel would clearly benefit a
> > component's community, or that I simply need.
> > All of this takes time; thow in this mailing list, JIRAs, PRs from
> GitHub,
> > and that's a lot to chew on. IOW, be patient, manage your expectations
> ;-)
> I never doubt this. I know you are busy and put a lot of effort on
> commons. And your helps/suggestions are actually really helpful in most of
> the times. Thank you.
> I'm just, kind of curious about how things works here normally.
> Thanks.
>
> Gary Gregory  于2020年6月12日周五 下午9:56写道：
>
>> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess  wrote:
>>
>> > >> 8. What should we do when we have a pr delayed for a long time? And
>> how
>> > >> long is thought to be an unusual long time for waiting? 3 days.1
>> week,or
>> > 1
>> > >> month?
>> >
>> > > They might have been forgotten, or there may other issues.
>> > > Examples?
>> >
>> > for 1 year example:
>> > https://github.com/apache/commons-lang/pull/428
>> > for half year example:
>> > https://github.com/apache/commons-vfs/pull/78
>> > (I have no idea whether it is already resolved, as I have not received
>> any
>> > report about it being resolved, and the pr is still not closed or marked
>> > resolved by someone.)
>> > for two weeks example:
>> > too many.
>> > As I said above, I have no better way for detecting whether a repo is
>> > "active", so I send some "trying minor prs" to every repo (nearly).
>> > Most of them have no response.
>> > No approving, no rejection, no modification suggestions.
>> > If you really wanna details, I will try to make a list for you.
>> >
>>
>> Speaking for myself, as a volunteer here, I do what I can, when I can,
>> with
>> a eye toward using my time wisely while balancing many other
>> responsibilities.
>> Commons has over 20 components, some I use at work, some I used at play,
>> some I do not use.
>> I do my best to pick low hanging fruits, fix bugs that could be
>> troublesome, and implement new features I feel would clearly benefit a
>> component's community, or that I simply need.
>> All of this takes time; thow in this mailing list, JIRAs, PRs from GitHub,
>> and that's a lot to chew on. IOW, be patient, manage your expectations ;-)
>>
>> HTH,
>> Gary
>>
>>
>> >
>> >
>> > Xeno Amess  于2020年6月12日周五 下午9:36写道：
>> >
>> > > >> Are they under a same (or at least
>> > > >> similar) management mechanism? Or just sharing a common prefix?
>> > >
>> > > > Do you mean the development tools (maven, git)?
>> > > > There some measure of "standardization" through the parent POM
>> > > > file, but nothing is really enforced.  The code style depends on the
>> > > > regular contributo

Re: some questions about commons projects.

[Xeno Amess]

> Being on the PMC means that your VOTE is _binding_
> I think you are assuming that there is a lot of hierarchy, structure, and
> formalities that are just not here ;-)
Yep, indeed.

Gary Gregory  于2020年6月12日周五 下午10:34写道：

> On Fri, Jun 12, 2020 at 10:22 AM Xeno Amess  wrote:
>
> > >> Speaking for myself, as a volunteer here, I do what I can, when I can,
> > with
> > >> a eye toward using my time wisely while balancing many other
> > >> responsibilities.
> > >> Commons has over 20 components, some I use at work, some I used at
> play,
> > >> some I do not use.
> > >> I do my best to pick low hanging fruits, fix bugs that could be
> > >> troublesome, and implement new features I feel would clearly benefit a
> > >> component's community, or that I simply need.
> > >> All of this takes time; thow in this mailing list, JIRAs, PRs from
> > GitHub,
> > >> and that's a lot to chew on. IOW, be patient, manage your expectations
> > ;-)
> > > I never doubt this. I know you are busy and put a lot of effort on
> > commons. And your helps/suggestions are actually really helpful in most
> of
> > the times. Thank you.
> > > I'm just, kind of curious about how things works here normally.
> > > Thanks.
> > I have a strange feeling as most of my prs are reviewed by you, a PMC,
> but
> > not a normal committer.
> > Is it a normal state? Or what wrongs/mistakes did I make?
> > Because I think normal committers should be the group who review most of
> > the prs, and PMC committers shall struggle for some more important
> things,
> > maybe I mis-understand somethings(again)?
> >
>
> Being on the PMC means that your VOTE is _binding_
> I think you are assuming that there is a lot of hierarchy, structure, and
> formalities that are just not here ;-)
>
> Gary
>
> Gary
>
>
> >
> > Xeno Amess  于2020年6月12日周五 下午10:01写道：
> >
> > > > Speaking for myself, as a volunteer here, I do what I can, when I
> can,
> > > with
> > > > a eye toward using my time wisely while balancing many other
> > > > responsibilities.
> > > > Commons has over 20 components, some I use at work, some I used at
> > play,
> > > > some I do not use.
> > > > I do my best to pick low hanging fruits, fix bugs that could be
> > > > troublesome, and implement new features I feel would clearly benefit
> a
> > > > component's community, or that I simply need.
> > > > All of this takes time; thow in this mailing list, JIRAs, PRs from
> > > GitHub,
> > > > and that's a lot to chew on. IOW, be patient, manage your
> expectations
> > > ;-)
> > > I never doubt this. I know you are busy and put a lot of effort on
> > > commons. And your helps/suggestions are actually really helpful in most
> > of
> > > the times. Thank you.
> > > I'm just, kind of curious about how things works here normally.
> > > Thanks.
> > >
> > > Gary Gregory  于2020年6月12日周五 下午9:56写道：
> > >
> > >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess 
> wrote:
> > >>
> > >> > >> 8. What should we do when we have a pr delayed for a long time?
> And
> > >> how
> > >> > >> long is thought to be an unusual long time for waiting? 3 days.1
> > >> week,or
> > >> > 1
> > >> > >> month?
> > >> >
> > >> > > They might have been forgotten, or there may other issues.
> > >> > > Examples?
> > >> >
> > >> > for 1 year example:
> > >> > https://github.com/apache/commons-lang/pull/428
> > >> > for half year example:
> > >> > https://github.com/apache/commons-vfs/pull/78
> > >> > (I have no idea whether it is already resolved, as I have not
> received
> > >> any
> > >> > report about it being resolved, and the pr is still not closed or
> > marked
> > >> > resolved by someone.)
> > >> > for two weeks example:
> > >> > too many.
> > >> > As I said above, I have no better way for detecting whether a repo
> is
> > >> > "active", so I send some "trying minor prs" to every repo (nearly).
> > >> > Most of them have no response.
> > >> > No approving, no rejection, no modification suggestions.
> > >> > If you really wanna details, I will try to

[all] suggestions about ci usage general rules.

[Xeno Amess]

Here are several suggestions about usage of travis-ci (or github ci or
other ci like appveyor).
It is not legal or must do or something, but just several simple rules that
make everybody be happier when dealing with ci.

*1. Always have all LST versions tested from project.source to ea.*
For example, if your repo uses jdk6, then it should be at least 6,7,8,11.
  if your repo uses jdk8, then it should be at least 8,11.

However if you want to add other jdks feel free to do so, but keep in mind
that you add more, it gets answered slower, and guys wait longer.

*2. If a known bug/issue causes some jdk version cannot work correctly on
travis-ci (thus you get a red cross instead of a green trigger), you MUST
choose one of the following two operations:(2.1 or 2.2)*
2.1 Track why it fails, and fix it immediately. Until it is finished, you
MUST_NOT merge any other pr into branch master. And you must do it in 3
days.
2.2 Track why it fails, and record the reason. After that you MUST put the
the errored jdk version into allow_failure.

*3. Only merge pr which ci pass. If a pr cannot pass ci, please let
its author fix it to be able to pass ci before you merge.*
The only exception is when situation come that the ci failure is not
related by this pr, but an older(or even ancient) bug, which can cause the
ci sometimes pass, other times fail, or the build script just can not build
normally anymore from some time point (usually when people use some plugin
and forget to force the plugin's version).
If so, record that bug, and choose one of the following three
operations:(2.1 or 2.2 or 3.1)
3.1  Track why it fails, and record the reason. After that you MUST
re-trigger your pr's ci build (by rebase & force-push), and do it until the
ci can pass.

*4. If you suddenly found your master branch cannot pass ci, you MUST pause
any other actions, and choose one of the following three operations:(2.1 or
2.2 or 3.1) *

*5. If all of the recent pending prs fail travis-ci, and the branch master
has not been updated for a long time (a long time here means several
months) then you MUST make a fork of this repo, and retrigger the ci on
your clone. If it also fails ci, you MUST pause any other actions, and
choose one of the following three operations:(2.1 or 2.2 or 3.1) *

*6. If after you merge a pr your branch master fails, first check have you
follow rule 3 and 4 perfectly. Then you MUST pause any other actions, and
choose one of the following three operations:(2.1 or 2.2 or 3.1)  *

This is the general rules me myself follow when managing my own projects.
I hope this will be helpful.
Glad to hear about your opinions.
Thanks.

Re: [commons-graph] branch master updated: Travis CI configuration.

[Xeno Amess]

Two failures and one error actually.
I will try to fetch the latest commit who CAN pass junit test, using binary
search.
Will send mail when I finish.

Gilles Sadowski  于2020年6月13日周六 上午6:21写道：

> Hi.
>
> 2020-06-12 21:43 UTC+02:00, Amey Jadiye :
> > On Fri, Jun 12, 2020 at 4:40 PM Gilles Sadowski 
> > wrote:
> >
> >> 2020-06-12 12:32 UTC+02:00, Xeno Amess :
> >> > Hi.
> >> > I see the current travis-ci scripts.
> >> > Do we really care only jdk8?
> >> > Should we also add at some other jdk versions, at least adding
> >> > openjdk11,
> >> > as it is a stable version?
> >> > Or this repo has some known bug on jdk11?
> >> >
> >>
> >> Before refining, we should get[1] a first build:
> >> https://travis-ci.org/github/apache/commons-graph
> >
> > +1
> > maybe you can check and merge my one upgrade PR to check this.
> > https://github.com/apache/commons-graph/pull/1
>
> I've merged the changes to see that Travis is set up,
> even though some unit tests are in error: Please have
> a look.
>
> Thanks,
> Gilles
>
> >
> > I don't see it on Travis though, maybe because I raised it before travis
> > setup.
> >
> > Regards,
> > Amey
> >
> >>
> >>
> >> Gilles
> >>
> >> [1] https://issues.apache.org/jira/browse/INFRA-20413
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-graph] branch master updated: Travis CI configuration.

[Xeno Amess]

Done.
Environment win10, jdk8.
Due to the binary search, the last pr in this repo who can pass all junit
tests is commit 967b9bed79f51040597d68ef98512a24b0e94e41 , which is at
6/11/2011,10:43PM
Suggest revert all changes after that time point, and track them one by one.
A project which can never pass its own junit tests is kindof.confusing.
And me myself will never consider about using it.



Xeno Amess  于2020年6月13日周六 上午7:27写道：

> Two failures and one error actually.
> I will try to fetch the latest commit who CAN pass junit test, using
> binary search.
> Will send mail when I finish.
>
> Gilles Sadowski  于2020年6月13日周六 上午6:21写道：
>
>> Hi.
>>
>> 2020-06-12 21:43 UTC+02:00, Amey Jadiye :
>> > On Fri, Jun 12, 2020 at 4:40 PM Gilles Sadowski 
>> > wrote:
>> >
>> >> 2020-06-12 12:32 UTC+02:00, Xeno Amess :
>> >> > Hi.
>> >> > I see the current travis-ci scripts.
>> >> > Do we really care only jdk8?
>> >> > Should we also add at some other jdk versions, at least adding
>> >> > openjdk11,
>> >> > as it is a stable version?
>> >> > Or this repo has some known bug on jdk11?
>> >> >
>> >>
>> >> Before refining, we should get[1] a first build:
>> >> https://travis-ci.org/github/apache/commons-graph
>> >
>> > +1
>> > maybe you can check and merge my one upgrade PR to check this.
>> > https://github.com/apache/commons-graph/pull/1
>>
>> I've merged the changes to see that Travis is set up,
>> even though some unit tests are in error: Please have
>> a look.
>>
>> Thanks,
>> Gilles
>>
>> >
>> > I don't see it on Travis though, maybe because I raised it before travis
>> > setup.
>> >
>> > Regards,
>> > Amey
>> >
>> >>
>> >>
>> >> Gilles
>> >>
>> >> [1] https://issues.apache.org/jira/browse/INFRA-20413
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [commons-graph] branch master updated: Travis CI configuration.

[Xeno Amess]

> This discussion requires another thread.

Well I don't think so, as I think this thread aims for making travis-ci can
pass.
And test failures are the reason why it cannot pass ci for now.
I don't see the value in creating another thread.

Btw: I tested (if my memory are correct, as I didn't make a log for it) the
latest commit (fail) , the first commit at year 2012(fail), the first
commit of the repo(pass), the first commit of year2011month10(fail),
the first commit of year2011month7(fail), and I tried every version
from year2011month7 back, and finally I get the last commit that can pass
all junit tests be 967b9bed79f51040597d68ef98512a24b0e94e41m ,which is just
3 hours after the repo created.

Btw2: Is it a usual thing in commons, for a repo's branch master can never
pass its own junit tests for years? I'm new here, knowing nearly nothing
about commons, and become very confused.
Btw3: And do the users of this repo know about this?

Gilles Sadowski  于2020年6月13日周六 上午9:52写道：

> 2020-06-13 1:43 UTC+02:00, Xeno Amess :
> > Done.
> > Environment win10, jdk8.
> > Due to the binary search, the last pr in this repo who can pass all junit
> > tests is commit 967b9bed79f51040597d68ef98512a24b0e94e41 , which is at
> > 6/11/2011,10:43PM
> > Suggest revert all changes after that time point, and track them one by
> > one.
>
> This discussion requires another thread.
>
> Regards,
> Gilles
>
> > A project which can never pass its own junit tests is
> kindof.confusing.
> > And me myself will never consider about using it.
> >
> >
> >
> > Xeno Amess  于2020年6月13日周六 上午7:27写道：
> >
> >> Two failures and one error actually.
> >> I will try to fetch the latest commit who CAN pass junit test, using
> >> binary search.
> >> Will send mail when I finish.
> >>
> >> Gilles Sadowski  于2020年6月13日周六 上午6:21写道：
> >>
> >>> Hi.
> >>>
> >>> 2020-06-12 21:43 UTC+02:00, Amey Jadiye :
> >>> > On Fri, Jun 12, 2020 at 4:40 PM Gilles Sadowski <
> gillese...@gmail.com>
> >>> > wrote:
> >>> >
> >>> >> 2020-06-12 12:32 UTC+02:00, Xeno Amess :
> >>> >> > Hi.
> >>> >> > I see the current travis-ci scripts.
> >>> >> > Do we really care only jdk8?
> >>> >> > Should we also add at some other jdk versions, at least adding
> >>> >> > openjdk11,
> >>> >> > as it is a stable version?
> >>> >> > Or this repo has some known bug on jdk11?
> >>> >> >
> >>> >>
> >>> >> Before refining, we should get[1] a first build:
> >>> >> https://travis-ci.org/github/apache/commons-graph
> >>> >
> >>> > +1
> >>> > maybe you can check and merge my one upgrade PR to check this.
> >>> > https://github.com/apache/commons-graph/pull/1
> >>>
> >>> I've merged the changes to see that Travis is set up,
> >>> even though some unit tests are in error: Please have
> >>> a look.
> >>>
> >>> Thanks,
> >>> Gilles
> >>>
> >>> >
> >>> > I don't see it on Travis though, maybe because I raised it before
> >>> > travis
> >>> > setup.
> >>> >
> >>> > Regards,
> >>> > Amey
> >>> >
> >>> >>
> >>> >>
> >>> >> Gilles
> >>> >>
> >>> >> [1] https://issues.apache.org/jira/browse/INFRA-20413
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-graph] branch master updated: Travis CI configuration.

[Xeno Amess]

Oh.
Then I guess work in this thread is already done.
Oh wait.
You might need this:
https://github.com/apache/commons-graph/pull/2

Gilles Sadowski  于2020年6月13日周六 上午10:11写道：

> 2020-06-13 4:05 UTC+02:00, Xeno Amess :
> >> This discussion requires another thread.
> >
> > Well I don't think so, as I think this thread aims for making travis-ci
> can
> > pass.
>
> No; this thread was about setting up Travis (as asked by Amey).
>
> > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Graph] Build fails (unit tests)

[Xeno Amess]

> IMO, the top priority is now to fix the failing unit tests;
> personally, I'm not going to merge any PR before that is
> achieved (and please refer to the JIRA identifier[1] in the
> corresponding commit/PR).

agreed.

And I still suggest revert back to the last version which can build, and
start an investigation/modification about every commit after that.
After all it is not good to leave hundreds of commits who fails tests in
branch master.
That is confusing when people try to learn about history of this repo / how
does the repo built from beginning.


Gilles Sadowski  于2020年6月13日周六 下午9:06写道：

> Hello.
>
> After the migration from SVN to "gitbox", we noticed that the
> _first_ build failed due to 3 unit tests not passing (see e.g. the
> Travis report  referred to the JIRA report[1]).
>
> The move to "git" was intended to make it easier for people
> willing to revive the [Graph] project.
>
> IMO, the top priority is now to fix the failing unit tests;
> personally, I'm not going to merge any PR before that is
> achieved (and please refer to the JIRA identifier[1] in the
> corresponding commit/PR).
>
> Furthermore, I'd suggest that branch "modularization"
> becomes the reference branch (in place of "master"[2]),
> since the latest batch of work for [Graph] was done on
> that one, seemingly leaving "master" behind (TBC by
> Amey?).  [This path might avoid subsequent work of
> merging the fixed (but outdated) "master" into the more
> recent branch that is bound to replace it anyway...]
>
> Thanks,
> Gilles
>
> [1] https://issues.apache.org/jira/browse/SANDBOX-510
> [2] Even though the names of the maven "modules" should
> be changed (for the sake of code layout "standardization"
> with other modular components such as "Commons RNG").
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Graph] Build fails (unit tests)

[Xeno Amess]

Hi.

> You are welcome to implement your suggestion

I want to, but this repo is out of my ability.
Although I do have some experiences in ICPC, the graph part is handled by
my team mates, and I personally nearly know nothing about any complex graph
algorithms.



Gilles Sadowski  于2020年6月13日周六 下午9:31写道：

> Hi.
>
> 2020-06-13 15:11 UTC+02:00, Xeno Amess :
> >> IMO, the top priority is now to fix the failing unit tests;
> >> personally, I'm not going to merge any PR before that is
> >> achieved (and please refer to the JIRA identifier[1] in the
> >> corresponding commit/PR).
> >
> > agreed.
> >
> > And I still suggest revert back to the last version which can build, and
> > start an investigation/modification about every commit after that.
>
> You are welcome to implement your suggestion and/or
> coordinate with Amey.
>
> > After all it is not good to leave hundreds of commits who fails tests in
> > branch master.
> > That is confusing when people try to learn about history of this repo /
> how
> > does the repo built from beginning.
>
> Another perspective: It reflects the actual history of the
> repository.
> Presumably, this would not have happened in a released
> component; at least, it was right for this component to be
> in the sand-box. ;-)
>
> Personally, I'd forget about the history prior to the move to
> git (viewed as the "initial" state from a source code donation),
> fix the issues and start refactoring.
>
> Regards,
> Gilles
>
> >
> > Gilles Sadowski  于2020年6月13日周六 下午9:06写道：
> >
> >> Hello.
> >>
> >> After the migration from SVN to "gitbox", we noticed that the
> >> _first_ build failed due to 3 unit tests not passing (see e.g. the
> >> Travis report  referred to the JIRA report[1]).
> >>
> >> The move to "git" was intended to make it easier for people
> >> willing to revive the [Graph] project.
> >>
> >> IMO, the top priority is now to fix the failing unit tests;
> >> personally, I'm not going to merge any PR before that is
> >> achieved (and please refer to the JIRA identifier[1] in the
> >> corresponding commit/PR).
> >>
> >> Furthermore, I'd suggest that branch "modularization"
> >> becomes the reference branch (in place of "master"[2]),
> >> since the latest batch of work for [Graph] was done on
> >> that one, seemingly leaving "master" behind (TBC by
> >> Amey?).  [This path might avoid subsequent work of
> >> merging the fixed (but outdated) "master" into the more
> >> recent branch that is bound to replace it anyway...]
> >>
> >> Thanks,
> >> Gilles
> >>
> >> [1] https://issues.apache.org/jira/browse/SANDBOX-510
> >> [2] Even though the names of the maven "modules" should
> >> be changed (for the sake of code layout "standardization"
> >> with other modular components such as "Commons RNG").
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [crypto] New Release

[Xeno Amess]

I have a feeling about both mingw or cygwin build output will be slower
than microsoft-visual-studio build output...
Just a feeling, but no evidence.

Alex Remily  于2020年6月14日周日 上午7:02写道：

> I used MinGW64.  It does indeed ship with make.  I can provide a link
> to the distribution I used if there's interest.
>
> On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin  wrote:
> >
> > Pretty sure I remember comments in the code about building with mingw
> > on Windows (not cygwin). That should have a version of make, too,
> > IIRC.
> >
> > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory 
> wrote:
> > >
> > > Except that you can't build on plain Windows because the build uses
> make
> > > and Microsoft version is called nmake. I might have to cobble up some
> > > cygwin thing...
> > >
> > > Gary
> > >
> > > On Sat, Jun 13, 2020, 18:02 Alex Remily  wrote:
> > >
> > > > I can't speak to how the original developers did the build, but all
> > > > the Windows builds that I did were on a Windows machine.  I always
> > > > assumed that the original developers just manually packed the release
> > > > jar with artifacts from each supported environment.  I never did any
> > > > investigation into the process.  Is cobbling together a release in
> > > > that manner really a non-starter here?
> > > >
> > > > Alex
> > > >
> > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory  >
> > > > wrote:
> > > > >
> > > > > Hi Matt:
> > > > >
> > > > > > I have:
> > > > > >
> > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h
> > > > > > /usr/i686-w64-mingw32/include/windows.h
> > > > > > /usr/share/mingw-w64/include/windows.h
> > > > > > /usr/x86_64-w64-mingw32/include/windows.h
> > > > > >
> > > > > > Case matters here, so I wonder if the original others did not
> cross
> > > > > compile
> > > > > > from Linux and instead built a little here, a little there, and
> so on.
> > > > > >
> > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where
> that is
> > > > > > supposed to be...
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker  wrote:
> > > > >
> > > > > > Are the Windows headers even available when using Ming32 or
> Cygwin?
> > > > > > That sounds more like a Visual Studio compiler thing.
> > > > > >
> > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory <
> garydgreg...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > The challenge is getting everything set up just right for
> building
> > > > the
> > > > > > > various OS profiles. This component is quite different in this
> > > > regard,
> > > > > > > getting help from the original contributors would be helpful.
> > > > > > >
> > > > > > > After much fiddling to install the proper packages, this
> builds OK:
> > > > > > >
> > > > > > > mvn package -DskipTests -P linux64
> > > > > > > mvn package -DskipTests -P linux32
> > > > > > >
> > > > > > > But these do not:
> > > > > > > mvn package -DskipTests -P win64
> > > > > > > mvn package -DskipTests -P win32
> > > > > > >
> > > > > > > due to:
> > > > > > >
> > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto
> ---
> > > > > > > [INFO] Executing tasks
> > > > > > >
> > > > > > > make:
> > > > > > >  [exec] make native CROSS_PREFIX=x86_64-w64-mingw32-
> > > > OS_NAME=Windows
> > > > > > > OS_ARCH=x86_64
> > > > > > >  [exec] make[1]: Entering directory
> '/mnt/c/git/commons-crypto'
> > > > > > >  [exec] x86_64-w64-mingw32-gcc
> > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include"
> > > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include
> > > > > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux"
> > > > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > > > > >
> > > > > >
> > > >
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > > > > > > -o
> > > > > > >
> > > > > >
> > > >
> target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o
> > > > > > >  [exec] Makefile:54: recipe for target
> > > > > > >
> > > > > >
> > > >
> 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o'
> > > > > > > failed
> > > > > > >  [exec] make[1]: Leaving directory
> '/mnt/c/git/commons-crypto'
> > > > > > >  [exec] Makefile:82: recipe for target 'win64' failed
> > > > > > >  [exec] In file included from
> > > > > > >
> > > > > >
> > > >
> src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0,
> > > > > > >  [exec]  from
> > > > > > >
> > > > > >
> > > >
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19:
> > > > > > >  [exec]
> > > > > > >
> > > > > >
> > > >
> src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10:
> > > > > > > fatal error: Windows.h: No such

[io] can we delete release 20030203.000550 in maven central?

[Xeno Amess]

every time my update tool chain thinks 20030203.000550 is a greater version
than 2.7 (actually it is, if see it in number).
So have we some way to delete it from maven central? (or rename it?)
The same problem happened in BeanUtils, version 20030211.134440

Re: [io] can we delete release 20030203.000550 in maven central?

[Xeno Amess]

"update toolchain" here means idea's package plugin, which seems have no
way to set up rules like rules in versions-maven-plugin.
[image: image.png]
Of course we can try to only use versions-maven-plugin.

But a setting like that just hides problem, it does not solve the problem.
The real problem is that "An older version have a larger version number
than a newer version"[1].
And nearly all rules about versioning forbids that [1].

Rob Spoor  于2020年6月14日周日 下午7:03写道：

> On 14/06/2020 12:40, Xeno Amess wrote:
> > every time my update tool chain thinks 20030203.000550 is a greater
> version
> > than 2.7 (actually it is, if see it in number).
> > So have we some way to delete it from maven central? (or rename it?)
> > The same problem happened in BeanUtils, version 20030211.134440
>
> That's why you can use a set of rules with the Maven versions plugin:
> https://www.mojohaus.org/versions-maven-plugin/version-rules.html
>
> For instance, here's part of the rules I use:
>
>   artifactId="commons-collections">
>
>  
>  200[34]\d{4}.*
>
>  
>
> In a similar way, you can exclude alpha, beta, release-candidate and
> milestone versions. You just need to find the proper regex.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [io] can we delete release 20030203.000550 in maven central?

[Xeno Amess]

Or if we should create commons-io2  and commons-BeanUtils2 like what
we've done in lang3, as @John Patrick  suggested?

Gary Gregory  于2020年6月14日周日 下午9:39写道：

> On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess  wrote:
>
> > every time my update tool chain thinks 20030203.000550 is a greater
> version
> > than 2.7 (actually it is, if see it in number).
> > So have we some way to delete it from maven central? (or rename it?)
> >
>
> Yes, but we will never do that. That would break applications depending on
> that version. There are rare cases where releases may be withdrawn.
>
> Gary
>
>
> > The same problem happened in BeanUtils, version 20030211.134440
> >
>

Re: About binary compatibility

[Xeno Amess]

why not add a bc detect in travis-ci scripts?

Gary Gregory  于2020年6月14日周日 下午9:42写道：

> In order to avoid posting the same answer here and on GitHib over and over,
> I tried to explain BC here:
>
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
> Feedback is most welcome.
>
> Gary
>

Re: [io] can we delete release 20030203.000550 in maven central?

[Xeno Amess]

It is strange to have an older version have a larger major version number
than a newer version.
Of course we might never witness a major version whose number be 1000+
in our life, but...
That just feels strange.


Gary Gregory  于2020年6月14日周日 下午9:52写道：

> On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess  wrote:
>
> > Or if we should create commons-io2  and commons-BeanUtils2 like what
> > we've done in lang3, as @John Patrick  suggested?
> >
>
> Why?
>
> Gary
>
>
> >
> > Gary Gregory  于2020年6月14日周日 下午9:39写道：
> >
> > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess 
> wrote:
> > >
> > > > every time my update tool chain thinks 20030203.000550 is a greater
> > > version
> > > > than 2.7 (actually it is, if see it in number).
> > > > So have we some way to delete it from maven central? (or rename it?)
> > > >
> > >
> > > Yes, but we will never do that. That would break applications depending
> > on
> > > that version. There are rare cases where releases may be withdrawn.
> > >
> > > Gary
> > >
> > >
> > > > The same problem happened in BeanUtils, version 20030211.134440
> > > >
> > >
> >
>

Re: About binary compatibility

[Xeno Amess]

> Sure, go for it.
>
> I think we can use the default goal in Maven and use it from both TravisCI
> and GitHib Actions

Done in https://github.com/apache/commons-lang/pull/555
Similar ways can be used on any project who use commons-parent as parent.

Gary Gregory  于2020年6月14日周日 下午10:14写道：

> Sure, go for it.
>
> I think we can use the default goal in Maven and use it from both TravisCI
> and GitHib Actions.
>
> Gary
>
> On Sun, Jun 14, 2020, 09:52 Xeno Amess  wrote:
>
> > why not add a bc detect in travis-ci scripts?
> >
> > Gary Gregory  于2020年6月14日周日 下午9:42写道：
> >
> > > In order to avoid posting the same answer here and on GitHib over and
> > over,
> > > I tried to explain BC here:
> > >
> > >
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > >
> > > Feedback is most welcome.
> > >
> > > Gary
> > >
> >
>

Re: About binary compatibility

[Xeno Amess]

Hi gary.
The post looks good, but I think you can add more details about how we
detect bc in commons.
about plugin and other tool chains we used in such perpose, and result
analyzing.

Emmanuel Bourg  于 2020年6月15日周一 上午6:04写道：

> Le 14/06/2020 à 15:41, Gary Gregory a écrit :
> > In order to avoid posting the same answer here and on GitHib over and
> over,
> > I tried to explain BC here:
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> >
> > Feedback is most welcome.
>
> 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
>
>

Re: Allow to pass varargs to ObjectUtils.getIfNull

[Xeno Amess]

for what you want, you can simply use
getFirstNonNull(final Supplier... suppliers)
and then
defaultIfNull(final T object, final T defaultValue)


Yeldos Tanikin  于2020年6月15日周一 下午6:20写道：

> Hi,
> I have a suggestion to a little bit improve ObjectUtils.getIfNull, can we
> allow to pass Supplier varargs instead of Supplier, sometimes it is
> very helpful, as well it will not break compatibility with the current
> version.
>
> As far as I understand I should write to you before creating a task, if I'm
> wrong, tell me, please
>
> --
> Yeldos Tanikin
>

Re: About binary compatibility

[Xeno Amess]

>  I kind of like inaging1 even if it is weird and even though we do not
have
> a precedent here in Commons. I'm curious what others think.

+1 from me.

Gary Gregory  于2020年6月16日周二 上午7:07写道：

> I can see filling in a small section for source compatibility but
> behavioral compatibility is just too vague.
>
> I kind of like inaging1 even if it is weird and even though we do not have
> a precedent here in Commons. I'm curious what others think.
>
> Gary
>
> On Mon, Jun 15, 2020, 18:58 Bruno P. Kinoshita  wrote:
>
> > Good stuff Gary! Couple questions.
> >
> > Q1/ Will there be a follow-up post on behavioral compatibility too? :)
> >
> > Q2/ Only component I'm working (meaning pushing for a release soon-ish)
> on
> > at the moment is [imaging] for some IIIF related stuff. Should we rename
> > the package from o.a.c.imaging to something like o.a.c.imaging1,
> preparing
> > for the 1.0 full release (it's still alpha)?
> >
> >
> > Thanks!
> >
> > Bruno
> >
> >
> >
> >
> >
> >
> > On Monday, 15 June 2020, 1:42:18 am NZST, Gary Gregory <
> > garydgreg...@gmail.com> wrote:
> >
> >
> >
> >
> >
> > In order to avoid posting the same answer here and on GitHib over and
> over,
> > I tried to explain BC here:
> >
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> >
> > Feedback is most welcome.
> >
> > Gary
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [lang] release 3.11 soon

[Xeno Amess]

Hi.

> I'd like to release 3.11 soon.

First, please review [lang-1546]
https://github.com/apache/commons-lang/pull/428 when you (or other
committer) have time. It shall take no more than half hour to review it.

Second, like I said before, I do have a plan to refine StringUtils and
CharSequenceUtils, and I'm making prs about that one by one.
So I really hope some guys have any ideas about reviewing [lang-1548]
https://github.com/apache/commons-lang/pull/534 and [lang-1549]
https://github.com/apache/commons-lang/pull/535

So it actually decided by how long do you mean `soon` here.
If it be like longer, like a month, then I think maybe we can do it before
3.12 .(at least, 1 month is enough for me to make the prs. but these prs
are blocking each other, so I think I must wait until the further prs in,
then I can make new prs.)
Or if you like to, we can delay the refine process to 3.12, that is no
problem.

Gary Gregory  于2020年6月16日周二 上午5:41写道：

> HI All,
>
> I'd like to release 3.11 soon. I've not looked at the new Locks class yet
> though.
>
> Gary
>

Re: [commons-parent] branch master updated: Update to latest plugins

[Xeno Amess]

Hi.
commons.build-helper's latest version is 3.1.0
should we upgrade it also?

btw, if you want to release a new version of parent I would +1 here.
And I think we can use the new version of parent to make lang can build on
java-ea.
Thus the release plan of lang 3.11 should be delayed to after the release
of newer version of parent.

sebb  于2020年6月16日周二 下午8:43写道：

> I was thinking of that, however I don't know how to do the Git tagging
> properly
>
> On Tue, 16 Jun 2020 at 13:37, Gary Gregory  wrote:
> >
> > Thanks Sebb!
> >
> > Do you feel like pushing out a release of commons-parent?
> >
> > Gary
> >
> > On Tue, Jun 16, 2020 at 8:10 AM  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > sebb pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-parent.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > >  new b56ab01  Update to latest plugins
> > > b56ab01 is described below
> > >
> > > commit b56ab016a8ca6ddbfe335e373c2a4a02655c6c4b
> > > Author: Sebb 
> > > AuthorDate: Tue Jun 16 13:10:47 2020 +0100
> > >
> > > Update to latest plugins
> > > ---
> > >  pom.xml | 8 
> > >  src/changes/changes.xml | 4 
> > >  2 files changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/pom.xml b/pom.xml
> > > index 056e85e..a34f690 100644
> > > --- a/pom.xml
> > > +++ b/pom.xml
> > > @@ -138,7 +138,7 @@
> > >
> 1.7
> > >  1.1
> > >  
> > > -5.0.1
> > > +5.1.0
> > >
> > >  
> > >   > > >${project.artifactId}-${commons.release.version} commons.release.name>
> > > @@ -384,7 +384,7 @@
> > >
> > >
> > >
> > > -3.0.5
> > > +3.5.0
> > >
> > >
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-net] branch master updated: Fix Javadoc complaint

[Xeno Amess]

It really can according to html.
But -1 for doing so.
btw that is why I hate html.

sebb  于2020年6月16日周二 下午11:25写道：

> On Tue, 16 Jun 2020 at 14:28, Gary Gregory  wrote:
> >
> > On Tue, Jun 16, 2020 at 8:53 AM  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > sebb pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/commons-net.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > >  new 32f8d54  Fix Javadoc complaint
> > > 32f8d54 is described below
> > >
> > > commit 32f8d5430225d5fcf2e9b3dbcb7f8ef9455df15b
> > > Author: Sebb 
> > > AuthorDate: Tue Jun 16 13:53:18 2020 +0100
> > >
> > > Fix Javadoc complaint
> > > ---
> > >  src/main/java/org/apache/commons/net/ftp/FTPClient.java | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > b/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > index 94cd7ff..964ae7f 100644
> > > --- a/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > +++ b/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > @@ -278,7 +278,7 @@ import org.apache.commons.net.io.Util;
> > >   * method, so the timing is partially dependent on how long each block
> > > transfer takes.
> > >   * 
> > >   * This keep-alive feature is optional; if it does not help or
> causes
> > > problems then don't use it.
> > > - * 
> > > + *
> > >
> >
> > That's not right either: HTML tags should _closed_
>
>  closing tags can be omitted according to:
>
> https://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1
>
>
> > gARY
> >
> > >   * @see #FTP_SYSTEM_TYPE
> > >   * @see #SYSTEM_TYPE_PROPERTIES
> > >   * @see FTP
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-net] branch master updated: Fix Javadoc complaint

[Xeno Amess]

> Is Javadoc HTML?
yep it is.
But like I said I hate HTML for allowing people not to close tags.
In many ways I'd prefer XHTML.

> Fixing the tags will be a lot of work.
Actually not that lot...
Give me several hours and I can clean them all...
But I'd prefer listening about others' opinions first.
Is there any other guy who wanna join this chat & give some opinions?


sebb  于2020年6月16日周二 下午11:39写道：

> On Tue, 16 Jun 2020 at 16:28, Xeno Amess  wrote:
> >
> > It really can according to html.
> > But -1 for doing so.
> > btw that is why I hate html.
>
> Is Javadoc HTML?
>
> AFAIK there are a lot of Commons Javadoc with unclosed  tags.
>
> So long as the generated docs look OK, I don't see any reason to spend
> any time adding closing tags. Fixing the tags will be a lot of work.
>
> For example, I counted the following:
>
> IO:
>  733
>  264
>
> NET:
>  543
>  59
>
> > sebb  于2020年6月16日周二 下午11:25写道：
> >
> > > On Tue, 16 Jun 2020 at 14:28, Gary Gregory 
> wrote:
> > > >
> > > > On Tue, Jun 16, 2020 at 8:53 AM  wrote:
> > > >
> > > > > This is an automated email from the ASF dual-hosted git repository.
> > > > >
> > > > > sebb pushed a commit to branch master
> > > > > in repository https://gitbox.apache.org/repos/asf/commons-net.git
> > > > >
> > > > >
> > > > > The following commit(s) were added to refs/heads/master by this
> push:
> > > > >  new 32f8d54  Fix Javadoc complaint
> > > > > 32f8d54 is described below
> > > > >
> > > > > commit 32f8d5430225d5fcf2e9b3dbcb7f8ef9455df15b
> > > > > Author: Sebb 
> > > > > AuthorDate: Tue Jun 16 13:53:18 2020 +0100
> > > > >
> > > > > Fix Javadoc complaint
> > > > > ---
> > > > >  src/main/java/org/apache/commons/net/ftp/FTPClient.java | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git
> a/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > > > b/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > > > index 94cd7ff..964ae7f 100644
> > > > > --- a/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > > > +++ b/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> > > > > @@ -278,7 +278,7 @@ import org.apache.commons.net.io.Util;
> > > > >   * method, so the timing is partially dependent on how long each
> block
> > > > > transfer takes.
> > > > >   * 
> > > > >   * This keep-alive feature is optional; if it does not help or
> > > causes
> > > > > problems then don't use it.
> > > > > - * 
> > > > > + *
> > > > >
> > > >
> > > > That's not right either: HTML tags should _closed_
> > >
> > >  closing tags can be omitted according to:
> > >
> > > https://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1
> > >
> > >
> > > > gARY
> > > >
> > > > >   * @see #FTP_SYSTEM_TYPE
> > > > >   * @see #SYSTEM_TYPE_PROPERTIES
> > > > >   * @see FTP
> > > > >
> > > > >
> > >
> > > -
> > > 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
>
>

[lang] consider about fixing some unit test failure in openjdk-ea before 3.11 release?

[Xeno Amess]

[ERROR] Errors:
3585[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:303->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3586[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:308->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3587[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:283->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3588[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:288->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3589[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:313->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3590[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:318->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3591[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:293->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3592[ERROR]   
FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:298->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
» Parse
3593[ERROR]   
FastDateParserTest.testLocales_LongNoEra_AD:303->testLocales:339->checkParse:364->checkParse:369
» Parse
3594[ERROR]   
FastDateParserTest.testLocales_LongNoEra_BC:308->testLocales:339->checkParse:364->checkParse:369
» Parse
3595[ERROR]   
FastDateParserTest.testLocales_Long_AD:283->testLocales:339->checkParse:364->checkParse:369
» Parse
3596[ERROR]   
FastDateParserTest.testLocales_Long_BC:288->testLocales:339->checkParse:364->checkParse:369
» Parse
3597[ERROR]   
FastDateParserTest.testLocales_ShortNoEra_AD:313->testLocales:339->checkParse:364->checkParse:369
» Parse
3598[ERROR]   
FastDateParserTest.testLocales_ShortNoEra_BC:318->testLocales:339->checkParse:364->checkParse:369
» Parse
3599[ERROR]   
FastDateParserTest.testLocales_Short_AD:293->testLocales:339->checkParse:364->checkParse:369
» Parse
3600[ERROR]   
FastDateParserTest.testLocales_Short_BC:298->testLocales:339->checkParse:364->checkParse:369
» Parse
3601[INFO]
3602[ERROR] Tests run: 6205, Failures: 0, Errors: 16, Skipped: 4

Re: [lang] consider about fixing some unit test failure in openjdk-ea before 3.11 release?

[Xeno Amess]

BTW, due to log in travis-ci openjdk14, the result of tests is :
[WARNING] Tests
run: 6130, Failures: 0, Errors: 0, Skipped: 4
And my local test on jdk15 (on windows) also shows [WARNING] Tests run:
6130, Failures: 0, Errors: 0, Skipped: 4
But the openjdk-ea on travis-ci shows[ERROR] Tests run: 6205, Failures: 0,
Errors: 16, Skipped: 4
Seems there be 75 additional tests running on travis-ci's openjdkea?
IMO witch might be the reason it fails.
Any ideas?



Xeno Amess  于2020年6月19日周五 上午4:41写道：

> [ERROR] Errors:
> 3585[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:303->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3586[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:308->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3587[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:283->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3588[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:288->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3589[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:313->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3590[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:318->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3591[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:293->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3592[ERROR]   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:298->FastDateParserTest.testLocales:339->FastDateParserTest.checkParse:364->FastDateParserTest.checkParse:369
>  » Parse
> 3593[ERROR]   
> FastDateParserTest.testLocales_LongNoEra_AD:303->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3594[ERROR]   
> FastDateParserTest.testLocales_LongNoEra_BC:308->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3595[ERROR]   
> FastDateParserTest.testLocales_Long_AD:283->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3596[ERROR]   
> FastDateParserTest.testLocales_Long_BC:288->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3597[ERROR]   
> FastDateParserTest.testLocales_ShortNoEra_AD:313->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3598[ERROR]   
> FastDateParserTest.testLocales_ShortNoEra_BC:318->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3599[ERROR]   
> FastDateParserTest.testLocales_Short_AD:293->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3600[ERROR]   
> FastDateParserTest.testLocales_Short_BC:298->testLocales:339->checkParse:364->checkParse:369
>  » Parse
> 3601[INFO]
> 3602[ERROR] Tests run: 6205, Failures: 0, Errors: 16, Skipped: 4
>
>