Restoring something like the svn browser

2019-10-10 Thread Phil Steitz 
Today I tried to find where a bug reported against what I suspect is 
DBCP 1.4 (I think that is likely what tomcat 7 pulls in) was fixed. It 
appears to be fixed in the 1.5 branch, but it is impossible now to 
actually see history via the browser.  The git browser has a "history" 
link, but clicking it results in a permission error.  The release tags 
for the 1.x releases appear to be gone as well.


The old svn browser is tantalizingly available, but just dead ends to a 
link saying dbcp has moved to git.  Is there any way we can make the svn 
browser available to see the old tags and revision history?


Phil

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

Re: [collections] BloomFilter or BitSet functions?

2019-10-10 Thread Gilles Sadowski 
Hello.

Le lun. 7 oct. 2019 à 19:42, Claude Warren  a écrit :
>
> As noted earlier I am preparing a contribution of Bloom Filter classes to
> the collections module.  As part of this submission there are several
> methods that operate on BitSets that are used as part  of Bloom Filter
> manipulation and analysis.  My question is, should these be contributed as
> Bloom Filter specific methods or would it be better to submit a BitSet
> function library.

What do you mean?
What would be the alternative?  How would usage change (from a
user perspective)?  Would it improve the design (e.g. be increasing
the "separation of concerns")?

Thanks,
Gilles

>
> The methods in question are:
> hammingDistance() = the cardinality (A xor B)
> jaccardDistance()  = the 1 - jaccardSimilarity()
> jaccardSimilarity() = cardinality(A xor B) / cardinality (A or B)
> cosineDistance() = 1 - cosineSimilarity()
> cosineSimilarity() = cardinality( A and B ) / (Sqrt( cardinality( A ) ) *
> Sqrt( cardinality( B )))
> estimatedLog = estimated log2 of the BitSet if considered a large unsigned
> int.
>
> Opinions requested.
>
> Claude
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

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

Re: [collections] ProtoBloomFilter.Builder -- opinions sought

2019-10-10 Thread Gilles Sadowski 
Hi.

Le lun. 7 oct. 2019 à 19:01, Claude Warren  a écrit :
>
> Greetings,
>
>  I am preparing a pull request to bring Bloom Filters in the the
> collections package.  The pull requests is at
> https://github.com/apache/commons-collections/pull/83 and the Jira ticket
> is https://issues.apache.org/jira/browse/COLLECTIONS-728
>
>
> The package has a builder that create ProtoBloomFilters that are then used
> to construct real bloom filters based on the desired "shape" of the
> Filter.  The question here is should the builder have the build() / with()
> methods that is currently has or should the number of methods be pruned?
>
> Currently the builder has the following methods
>
> build()
> build(byte)
> build(byte[])
> build(ByteBuffer)
> build(ProtoBloomFilter)
> build(String)
> with(byte)
> with(byte[])
> with(ByteBuffer)
> with(ProtoBloomFilter)
> with(String)
>
> It has been suggested that this should be reduced to
>
> build()
> with(byte)
> with(byte[])
> with(ByteBuffer)
> with(ProtoBloomFilter)
> with(String)

+1 to a lean API.

>
> The reasoning behind this is that is is akin to building a message digest.
> The java.security.MessageDigest class has multiple digest() and update()

The number of variants is lower (but even in that case I don't think
that it was warranted).

> methods that are logically the same as the build() and with() methods in
> the ProtoBloomFilter.Builder.  Thus the ProtoBloomFilter.Builder follows
> the same pattern.

Since the classes are not directly related, why should we follow
the (dubious, IMO) pattern?
Best is to keep the API lean, and let future usage dictate whether this
must be revised.

Best,
Gilles

>
> If you have an opinion please respond.
>
> Claude
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

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

Re: [exec] Update from Java 5 to 6

2019-10-10 Thread sebb 
On Thu, 10 Oct 2019 at 08:53, John Patrick  wrote:
>
> what about people wanting to use it on java 12 or java 13.

Please explain what you mean.

Are you saying that code compiled with Java 5 will not run on Java 12+ ?
Is not, why not?

> if java 1.5 and not wanting to upgrade is the argument, why would they be 
> upgrading the software...

It's very different upgrading a single component as opposed to
upgrading the JVM which runs multiple components.
Much easier to test and revert.

> if a company is choosing to use and run an out of support jvm’s then it is a 
> risk they are choosing to accept, either implicity or explicitly.
>
> maven and modules are two different things, in a few releases time the 
> classpath disappears and so any framework/jar that has not upgraded won’t 
> execute on the modern and current jvm.
>
> Sent from my iPhone
>
> > On 10 Oct 2019, at 08:40, Luis Panadero Guardeño 
> >  wrote:
> >
> > The problem sometimes not are the developers and their desire of 
> > upgrading. The problem are the clients that don't desire to upgrade the JVM 
> > that have installed in their servers.
> > I had a case where a client was running a Sun Java 5 JVM with a bug on 
> > String class that sometimes calculated bad string lengths and was making to 
> > our product to fail. The solution was to updated to a more modern JVM, but 
> > they don't like to do it.
> >
> >
> > 
> > De: Xeno Amess 
> > Enviado: jueves, 10 de octubre de 2019 8:16
> > Para: Commons Developers List 
> > Asunto: Re: [exec] Update from Java 5 to 6
> >
> > +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:

Re: [exec] Update from Java 5 to 6

2019-10-10 Thread John Patrick 
what about people wanting to use it on java 12 or java 13.

if java 1.5 and not wanting to upgrade is the argument, why would they be 
upgrading the software...

if a company is choosing to use and run an out of support jvm’s then it is a 
risk they are choosing to accept, either implicity or explicitly.

maven and modules are two different things, in a few releases time the 
classpath disappears and so any framework/jar that has not upgraded won’t 
execute on the modern and current jvm.

Sent from my iPhone

> On 10 Oct 2019, at 08:40, Luis Panadero Guardeño  
> wrote:
> 
> The problem sometimes not are the developers and their desire of upgrading. 
> The problem are the clients that don't desire to upgrade the JVM that have 
> installed in their servers.
> I had a case where a client was running a Sun Java 5 JVM with a bug on String 
> class that sometimes calculated bad string lengths and was making to our 
> product to fail. The solution was to updated to a more modern JVM, but they 
> don't like to do it.
> 
> 
> 
> De: Xeno Amess 
> Enviado: jueves, 10 de octubre de 2019 8:16
> Para: Commons Developers List 
> Asunto: Re: [exec] Update from Java 5 to 6
> 
> +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
>> 
> 
>

RE: [exec] Update from Java 5 to 6

2019-10-10 Thread Luis Panadero Guardeño 
The problem sometimes not are the developers and their desire of upgrading. The 
problem are the clients that don't desire to upgrade the JVM that have 
installed in their servers.
I had a case where a client was running a Sun Java 5 JVM with a bug on String 
class that sometimes calculated bad string lengths and was making to our 
product to fail. The solution was to updated to a more modern JVM, but they 
don't like to do it.



De: Xeno Amess 
Enviado: jueves, 10 de octubre de 2019 8:16
Para: Commons Developers List 
Asunto: Re: [exec] Update from Java 5 to 6

+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: [exec] Update from Java 5 to 6

2019-10-10 Thread 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