> I already commented elsewhere on why this is not a good fit for IO My bad, I did not realise that discussion is closed with final resolution. I read "what do others think?" and thought that it is about continuing discussion.
> Instead of keeping on arguing to shove your library in IO I thought about this discussion as a discussion, sorry if I am annoying you. I always think that being open to discussion and finding solutions, talking to other people is a good strategy: the probability to find a good solution is higher in this case. And sorry, but, honestly, I still don't see any good arguments (or few). The last one, about ANT, seems to me (just in my opinion, maybe wrong) a not very good argument. And I tried to explain why, maybe not so clearly; since you mention ANT again, my arguments are definitely not clear enough; Apache ANT is great, but there is no such functionality, in my opinion. Also, if I remember correctly, I tried to explain why Commons CSV is not what my solution is doing. If you believe that in-memory sort or csv parsing is what, roughly speaking, my solution is doing (or these solutions can be compared) then we have different points of view, and there would not be consensus. And I think this is also my fault. > I would survey other projects (see above) to see if common functionality could be extracted and more importantly if these projects would then be interested in relying on a new library (where it may reside) instead of maintaining their own code. > ... > and maybe elsewhere (Tika, Lucene, Solr, Spark?) Other Apache libraries - great! I will think about it. Thank you for that point. It's really great. I already said above that I am not insisting on Commons IO. I am just looking for alternatives and want to hear other people's opinions. Maybe some other Commons or non-Commons library, I am not familiar with the whole ecosystem. Maybe someone else could give me a hint. And you actually did it, twice about ANT and several times about Commons CSV, I really appreciate it. That was the one of the reasons why I wrote here. JDK itself supports Files and IO operations, also it supports sorting and binary search. Proposed functionality is out of JDK's scope, for sure, but it seemed to me that this is close to what JDK offers. Obviously I was wrong. I think this discussion can be finished. If someone else has something to add please feel free to email me directly. Again, sorry for disturbing. I didn't want to bother anyone, and didn't realise that it is what I'm doing. Thanks for taking the time and for trying to explain to me where I'm wrong. Have a nice day! One more thing > Too much like a database operation, IO is a lower level library, and so on. One of my colleagues also thinks that Commons-IO is not quite a suitable place for this proposition. So I'm totally sure that this is really not a suitable place. On Thu, Jul 20, 2023 at 4:16 PM Gary Gregory <garydgreg...@gmail.com> wrote: > I already commented elsewhere (can't recall if it was on this list or > github) on why this is not a good fit for IO. Too much like a database > operation, IO is a lower level library, and so on. IO is not a kitchen sink > for anything related to IO. Like Lang, it was initially conceived as a > library for low level operation that could be imagined to be in the JDK. > It's actually perfectly fine that the JDK does not contain such operations > as it should not be a kitchen sink either, but only provide primitive > operations. IO also does not contain CSV operations, that's in Commons CSV. > IO also does not contain high-level operations, projects like Apache Tika, > Lucene, and Solr do that. This still feels like a component that provides > one narrow purpose that should live in it's own project, which it already > does, yours, and also happens to already exist within Apache in Ant and > maybe elsewhere (Tika, Lucene, Solr, Spark?). So I think you are going > about this backward: Instead of keeping on arguing to shove your library in > IO, I would survey other projects (see above) to see if common > functionality could be extracted and more importantly if these projects > would then be interested in relying on a new library (where it may reside) > instead of maintaining their own code. It does matter if the common code is > derived from your library or existing projects (assuming proper licensing), > what matters is improving the Apache ecosystem, and FOSS in general. If you > are interested in I/O code and this interest matches the Commons IO > component of the Commons project, then great, there are some recent and not > so recent Jira tickets that could use some attention. > > Gary > > On Thu, Jul 20, 2023, 08:09 ssz <sss.z...@gmail.com> wrote: > > > That's great! > > - But ANT is quite an ancient system, and it is now relatively unknown. > > - And it is relatively heavy. Maybe it's better to have single-function > in > > the dedicated library or in well-known library with other useful features > > - It uses in-memory sorting: > > > > > https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/filters/SortFilter.java#L352 > > - What about binary search? > > > > On Thu, Jul 20, 2023 at 2:56 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > Note that Apache Ant already provides similar functionality: > > > > > > > > > https://ant.apache.org/manual/api/org/apache/tools/ant/filters/SortFilter.html > > > > > > Gary > > > > > > On Thu, Jul 20, 2023, 07:38 Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > > > Hi. > > > > > > > > [Disclaimer: I'm not a user nor a developer of "Commons IO", so > > > > I'm not the most suitable for entertaining this conversation and, > > > > surely, I shouldn't be the only one...] > > > > > > > > Le jeu. 20 juil. 2023 à 10:33, ssz <sss.z...@gmail.com> a écrit : > > > > > > > > > > Hi > > > > > Sure, I will support my code. > > > > > I have a lot of other opensource projects, not so much free time. > > > > > > > > I have to point out that the two sentences seem to neutralize > > > > themselves... > > > > > > > > > But this code will have the highest priority as Commons is used by > > > > > thousands of developers. > > > > > > > > That's what I've heard, but did not see much of a proof: We have no > > > > reliable way to know where "Commons" code is used. [This was a > > > > feature of open-source, but new regulations might make it a > > liability...] > > > > More importantly, if true, only a very tiny fraction of those users > > share > > > > their experience here, so that a quite small number of "regular" > > > > developers end up deciding what is useful. Almost inevitably, the > > > > selection is biased... > > > > > > > > > My other projects are used by hundreds of people. > > > > > > > > That's great, but would not convince (based on the lack of feedback) > > > > a committer here who is not among those users. > > > > > > > > The general problem is: > > > > 1. The active team is not getting bigger. > > > > 2. Those "regular" developers find they have already too much to > > > > handle. > > > > 3. Hence they tend to not easily accept contributions that are (or > > > > seem) likely to require time which they don't have. > > > > 4. This puts off would-be contributors that could have become part > > > > of the active team. > > > > 1. The active team is not getting bigger... > > > > > > > > So I'm trying to find other arguments... > > > > Which projects (ASF?) depend on your proposed contribution? > > > > > > > > Regards, > > > > Gilles > > > > > > > > >>> [...] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > >
