Jenkins build is back to normal : commons-jcs #178

[Apache Jenkins Server]

See 


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

Commons CLI Nested Groups

[John Patrick]

I've posted a message to the users list, but on reflecting I think
what I'm trying to achieve might be beyond commons-cli current
ability.

If I fork and work on adding nested OptionGroup's, would it stand a
change of being merged?
Is it a feature you want to support/provide?

I want to check with dev's before wasting time on the potential feature...

cheers,
John

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

Re: [Math] Changes on the 3.x line

[Ralph Goers]

> On Oct 12, 2016, at 4:10 PM, Gilles  wrote:
> 
> IIRC, many PMC members did not "like" the idea of having more
> components.
> Even less so if those components are being extracted from Commons
> Math.
> The least "problematic" one, Commons RNG, barely collected the
> number of required votes for a release.
> 
> Has that changed?
> Shall we request git repositories for the candidate components
> which I suggested back in May?


To be clear, Apache Commons currently lists about 40 sub-projects. These 
projects are typically small and not closely related with any other sub-project 
in any clear way.  The objection isn’t to adding more sub-projects, it is to 
adding more sub-projects that seem related closely enough that really belong 
together.  However, I don’t believe anyone objected to Commons Math being a 
multi-module project.

I would object to creating new Commons components that are forked off from 
Commons Math that have no maintainers. If there is code the Commons Math team 
doesn’t want then just get rid of it in your new version.

Ralph

[jcs] Please review! was: svn commit: r1764695 - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/auxiliary/disk/indexed/ main/java/org/apache/commons/jcs/utils/stru

[Thomas Vandahl]

Hi folks,

On 13.10.16 16:25, t...@apache.org wrote:
> Author: tv
> Date: Thu Oct 13 14:25:04 2016
> New Revision: 1764695
> 
> URL: http://svn.apache.org/viewvc?rev=1764695=rev
> Log:
> Fix SortedPreferentialArray to actually do what was is supposed to do
> 
> Modified:
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskElementDescriptor.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/SortedPreferentialArray.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/test/java/org/apache/commons/jcs/utils/struct/SortedPrefArrayUnitTest.java

When I looked into the tests of SortedPreferentialArray to see whether
this could be replaced with some JDK standard stuff, I found that it has
a number of severe problems. IMHO, it simply doesn't work. It doesn't
even sort correctly.

Now this class is used as a recycle bin in the IndexedDiskCache which,
to my knowledge, is a quite popular component within JCS.

Am I completely mistaken or is this functionality so unimportant that it
doesn't make any difference?

I replaced a lot of code with a reference to a ConcurrentSkipListSet and
managed to get all tests to pass again.

Could some kind soul please take a few cycles to review this commit and
the related code in IndexedDiskCache? I would like some help with
answering the following questions:

- The recycle bin contains elements of type
IndexedDiskElementDescriptor. Obviously, these elements were compared by
their size (len field) only, not their offset (pos field), so that
storage chunks of identical size are considered equal. Nevertheless,
this somehow seemed to work, even in the unit test where all elements
are of the same size. But why?

- The old implementation uses a fixed size array to store the elements.
If more elements were added, the smallest elements were discarded. Does
this actually make any sense?

- After my changes, the disk cache should recycle used storage chunks
more effectively. Can someone with a real-world application confirm this?

- Do I miss some other sophisticated feature in the code I removed?

Thank you in advance for any time you may be able to donate.

Bye, Thomas.


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

Re: [Math] Changes on the 3.x line

[Gilles]

On Thu, 13 Oct 2016 10:18:36 -0700, Gary Gregory wrote:
On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 


wrote:



> On Oct 12, 2016, at 4:10 PM, Gilles 
wrote:
>
> IIRC, many PMC members did not "like" the idea of having more
> components.
> Even less so if those components are being extracted from Commons
> Math.
> The least "problematic" one, Commons RNG, barely collected the
> number of required votes for a release.
>
> Has that changed?
> Shall we request git repositories for the candidate components
> which I suggested back in May?


To be clear, Apache Commons currently lists about 40 sub-projects. 
These

projects are typically small and not closely related with any other
sub-project in any clear way.  The objection isn’t to adding more
sub-projects, it is to adding more sub-projects that seem related 
closely

enough that really belong together.  However, I don’t believe anyone
objected to Commons Math being a multi-module project.

I would object to creating new Commons components that are forked 
off from

Commons Math that have no maintainers.


It is "Commons Math" that does not have maintainers.

The new components, would, conspicuously, have maintainers.
That's one of the main arguments in favour of this option.


If there is code the Commons Math
team doesn’t want then just get rid of it in your new version.


This option had been rejected in previous discussions, when I
suggested that I would not release code that I could not
maintain.


Gilles



+1

Gary



Ralph





--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition





JUnit in Action, Second Edition





Spring Batch in Action




Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory



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

Re: [Math] Changes on the 3.x line

[Gary Gregory]

On Thu, Oct 13, 2016 at 1:15 AM, Gilles 
wrote:

> On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote:
>
>> On Oct 12, 2016 4:17 PM, "Gilles"  wrote:
>>
>>>
>>> On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:
>>>

 On Oct 12, 2016 3:34 PM, "Gilles"  wrote:

>
>
> On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:
>
>>
>>
>> Le 12/10/2016 à 18:45, Gilles a écrit :
>>
>> So, what you say in substance is that you'd rather _wait_ for
>>> someone to come by who will want to work with you on 3.x, rather
>>> than continue with people, here and now, a work (CM4) that
>>> started more than 3 years ago.
>>>
>>
>>
>>
>> To be clear, I have no plan to maintain CM 3. I applied a small bug
>> fix
>> to CM 4, I just thought it would be nice to backport it if ever a new
>>
> CM
>>
>>> 3 release is required. That's all.
>>
>
>
>
> That backport served as an example that could lead to a broader
> reflection on the future of a project and the "community" around
> it; but you ignored it, again, by expressly cutting that part of
> my message.
>
>
> I'm doing open source mostly for fun, my motivation is to help and make
>> something useful to others, and if a fixed CM 3 makes someone happy,
>> then so am I.
>>
>
>
>
> I am sad that those one-shots gives the false impression that
> CM3 (or CM4) is alive.
>
> Some people here could have the project to maintain CM3; even
> if I'd prefer that they would work on CM4, they are of course
> free to decide where they want to contribute.
>
> However, I find it extremely uneasy that there is no roadmap
> whatsoever; only criticism of what I proposed.
>
> Is that fix worth a CM 3.7 release?
> If not, and nobody works towards a release, what did the
> reporter actually gain?
>


 Sometimes, a user just wants a bug fix in an easy to apply release. The
 liveliness of the project switches state as soon as the fix is
 delivered.
 Release notes can warn that new features are only happening on the
 master
 branch. If I get a bug fix I am happy ;-)

>>>
>>>
>>> This is all fine, in "theory". But:
>>>  * Who is going to _make_ a release for each applied patch?
>>>
>>
>> Speaking here only about 3.x...
>>
>> Whomever feels like it! :-) We do not have ownership as you well know. I
>> do
>> not have a need for a patch today and I do not foresee needing one, but I
>> would certainly not be shy about cutting an RC if I needed one.
>>
>
> Even if he wished to do it, the reporter and patch provider could
> not do it (unless he is a committer already).
>
> Will you grant the privilege on the basis of one patch?


I should have been clearer, sorry. I meant to say that it is up to a
Commons committer (which means an Apache Committer really) to step up and
do the release. The PMC still gets to VOTE of course, so it makes sense to
discuss fixes and releases on the ML to see what would put -1's in the path
of a release once an RM steps forward, this is no different than another
component.



>
>
>  * Why this fix and not the other ones reported on JIRA?
>>>
>>
>> It's up to the volunteer that steps up, with reasonable feedback from this
>> peanut gallery :-)
>>
>
> PMC members do not ask for feedback.
> They do as they wish.
> Usually, that's fine.
> But in the case of a project that is in a bad situation like
> CM (I call "bad", the shift from "bug report is handled within
> hours" to "unmaintained"), it's not.
>
>  * If a release should be considered only after all reported
>>>issues have been examined, who is going to do that work?
>>>
>>
>> See above.
>>
>
> Well, the above is a non-answer.
>
> No "privileged" developer is likely to spend his time doing
> point releases.
>

What's a "privileged" developer? In the past I've cur releases for selfish
needs: I need it at work or for a personal project. I've also cut them just
because it bugs me to see fixes pending in changes.xml and no reason not to
push them out. It's also a matter of time.

Gary

So there should be a roadmap such as "new point release every
> 6 months, containing whatever has been fixed".
>
> Otherwise, why would a contributor be motivated to provide a
> patch?
>
>
>>> Where is the roadmap?
>>>
>>
>> We do not need a roadmap for 3.x fixes IMO.
>>
>
> I do not agree; I gave the reason above.
>
> For 4.x, the answer is the same as it has always been, we discuss on the
>> ML. How else would it happen? At an Apache conference or meetup I
>> suppose...
>>
>
> I've discussed a lot on the ML.
> I've proposed things, and there has been no alternative (I do not
> call letting the code rot, an alternative).
>
> Don't you think that having maintained CM alone during 6 months
> (from 

Re: [Math] Changes on the 3.x line

[Gary Gregory]

On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 
wrote:

>
> > On Oct 12, 2016, at 4:10 PM, Gilles 
> wrote:
> >
> > IIRC, many PMC members did not "like" the idea of having more
> > components.
> > Even less so if those components are being extracted from Commons
> > Math.
> > The least "problematic" one, Commons RNG, barely collected the
> > number of required votes for a release.
> >
> > Has that changed?
> > Shall we request git repositories for the candidate components
> > which I suggested back in May?
>
>
> To be clear, Apache Commons currently lists about 40 sub-projects. These
> projects are typically small and not closely related with any other
> sub-project in any clear way.  The objection isn’t to adding more
> sub-projects, it is to adding more sub-projects that seem related closely
> enough that really belong together.  However, I don’t believe anyone
> objected to Commons Math being a multi-module project.
>
> I would object to creating new Commons components that are forked off from
> Commons Math that have no maintainers. If there is code the Commons Math
> team doesn’t want then just get rid of it in your new version.
>

+1

Gary

>
> Ralph




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[VOTE] Release Apache Commons Weaver 1.3 based on RC1

[Matt Benson]

I would like to release the [weaver] component.

Apache Commons Weaver 1.3 RC1 is available for review at:
  https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16504).

Maven artifacts are at:
  https://repository.apache.org/content/repositories/orgapachecommons-1208 .

Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.

The Subversion tag is:
  http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.3_RC1
 (r1764770).

Site (note some links may be broken; this will be fixed when the site
is deployed):
  http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/index.html

RAT Report:
  http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/rat-report.html

Quality Reports (PMD/Checkstyle/Findbugs/japicmp):

http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/commons-weaver-parent/commons-weaver-processor/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/commons-weaver-parent/commons-weaver-antlib/project-reports.html

Note that compatibility (japicmp) reports have only been produced for
artifacts that could conceivably be used programmatically by downstream
users: namely, *not* weaver modules.

Keys: https://dist.apache.org/repos/dist/release/commons/KEYS

Please review the release candidate and vote.
  This vote will close no sooner than 72 hours from now, i.e. after
2100UTC 16-October 2016

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

  Thanks!

[VOTE] Release Apache Commons Lang 3.5 based on RC2

[Benedikt Ritter]

Hi,

finally I found the time to prepare Apache Commons Lang 3.5 RC2 :-)
We could not release RC1, because I messed up the release archives. They
contained some snapshot artifacts. This has been fixed in RC2. Furthermore
LANG-1275 has been incorporated.

Lang 3.5 RC2 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/lang/LANG_3_5_RC2 (svn
revision 16505)

Tag name:
   LANG_3_5_RC2 (signature can be checked from git using 'git tag -v')

Tag URL:

https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=commit;h=36f98d87b24c2f542b02abbf6ec1ee742f1b158b

Commit ID the tag points at:
   36f98d87b24c2f542b02abbf6ec1ee742f1b158b

Maven artifacts are here:
  https://repository.apache.org/content/repositories/orgapachecommons-1209

These are the Maven artifacts and their hashes:

commons-lang3-3.5-javadoc.jar
(SHA1: 337310e98410d577aca675930bb46405a0a8fb0c)
commons-lang3-3.5-sources.jar
(SHA1: f7d878153e86a1cdddf6b37850e00a9f8bff726f)
commons-lang3-3.5-test-sources.jar
(SHA1: dfb8a086a03cc9499cff808733fac667f5f50688)
commons-lang3-3.5-tests.jar
(SHA1: 8ca309192f104265c67a1570245ae827a8650af9)
commons-lang3-3.5.jar
(SHA1: 6c6c702c89bfff3cd9e80b04d668c5e190d588c6)
commons-lang3-3.5.pom
(SHA1: 08b969f02dfa03fa493fd6eba4cb9dcceea5aefd)

I've tested with JDK 1.6 using Maven 3.2.5 and Java 7, 8 and Java 9 EA
using Maven 3.2.5.
Note that there are some problems when building on Java 9. We're currently
investigating this, see https://issues.apache.org/jira/browse/LANG-1265
To build on Java 9 you need to explicitly set the local provide to JRE:

  mvn -Djava.locale.providers=JRE clean test

Details of changes since 3.4 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/lang/LANG_3_5_RC2/RELEASE-NOTES.txt
  http://home.apache.org/~britter/commons/lang/3_5_RC2/changes-report.html

Site:
  http://home.apache.org/~britter/commons/lang/3_5_RC2

Clirr Report (compared to 3.4):
  http://home.apache.org/~britter/commons/lang/3_5_RC2/clirr-report.html
(sorry, I messed up the site build and had to add the Clirr report
manually...)

Note that Clirr reports several errors due to additions in the interface
org.apache.commons.lang3.time.DatePrinter
These are considered okay, since the DatePrinter interface is not meant to
be implemented by clients. This change is documented in the release notes.

RAT report:
  http://home.apache.org/~britter/commons/lang/3_5_RC2/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now,
i.e. sometime after 22:30 UTC+2 16-October 2016.

[ ] +1 Release these artifacts
[ ] +0 Okay, but...
[ ] -0 Okay, but really should fix...
[ ] -1 I oppose this release because...

Thank you,
Benedikt

[daemon] restart and shutdown behavior?

[Mori Bellamy]

i'm using commons-daemon on linux (so, jsvc). and, i'm trying to understand
when jsvc will restart the managed java app, and when it will not.

I think it all boils down to this snippet in java.c:

272 opt[x].optionString = strdup("abort");
> 273 jsvc_xlate_to_ascii(opt[x].optionString);
> 274 opt[x].extraInfo = (void *)java_abort123;
> 275 arg.options = opt;


I think the controller process only restarts my process (the "child") when
the child exits with 123? and i think the child only exits with 123 if the
JVM calls the "abort" hook. does that sound right?

so, please help me brainstorm all of the scenarios when the abort hook is
called. i think the intent is to restart only when the "jvm crashes" (from
https://commons.apache.org/proper/commons-daemon/jsvc.html) but i don't
know what that means.


-- 
Thanks,
Mori Bellamy

Build failed in Jenkins: commons-jcs #179

[Apache Jenkins Server]

See 

Changes:

[tv] Cleanup

[tv] Remove unnecessary code

--
[...truncated 931 lines...]
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IRequireScheduler.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/ICacheObserver.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/ICacheElement.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IShutdownObservable.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/ICompositeCacheManager.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IElementSerializer.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IShutdownObserver.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/ICacheService.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/behavior/IZombie.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheGroup.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/ZombieCacheServiceNonLocal.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheWatchRepairable.java
A commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/behavior
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/behavior/IMemoryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractMemoryCache.java
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/lru
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/lru/LRUMemoryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/lru/LHMLRUMemoryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/lru/package.html
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/fifo
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/fifo/FIFOMemoryCache.java
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/mru
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/mru/MRUMemoryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/mru/package.html
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/soft
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/soft/SoftReferenceMemoryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/soft/package.html
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/shrinking
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/shrinking/ShrinkerThread.java
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/util
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/util/MemoryElementDescriptor.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/util/SoftReferenceElementDescriptor.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/util/DefaultMemoryElementDescriptor.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/package.html
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheElementSerialized.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/ZombieCacheService.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CacheListeners.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/CompositeCacheAttributes.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/AbstractCacheEventQueue.java
A commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/AbstractAuxiliaryCache.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/AuxiliaryCacheAttributes.java
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/AuxiliaryCacheFactory.java
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral
AU
commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/LateralCacheAttributes.java
A 
commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/lateral/behavior
AU

Re: [Math] Changes on the 3.x line

[Ralph Goers]

> On Oct 13, 2016, at 10:50 AM, Gilles  wrote:
> 
> On Thu, 13 Oct 2016 10:18:36 -0700, Gary Gregory wrote:
>> On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 
>> wrote:
>> 
>>> 
>>> > On Oct 12, 2016, at 4:10 PM, Gilles 
>>> wrote:
>>> >
>>> > IIRC, many PMC members did not "like" the idea of having more
>>> > components.
>>> > Even less so if those components are being extracted from Commons
>>> > Math.
>>> > The least "problematic" one, Commons RNG, barely collected the
>>> > number of required votes for a release.
>>> >
>>> > Has that changed?
>>> > Shall we request git repositories for the candidate components
>>> > which I suggested back in May?
>>> 
>>> 
>>> To be clear, Apache Commons currently lists about 40 sub-projects. These
>>> projects are typically small and not closely related with any other
>>> sub-project in any clear way.  The objection isn’t to adding more
>>> sub-projects, it is to adding more sub-projects that seem related closely
>>> enough that really belong together.  However, I don’t believe anyone
>>> objected to Commons Math being a multi-module project.
>>> 
>>> I would object to creating new Commons components that are forked off from
>>> Commons Math that have no maintainers.
> 
> It is "Commons Math" that does not have maintainers.
> 
> The new components, would, conspicuously, have maintainers.
> That's one of the main arguments in favour of this option.
> 
>>> If there is code the Commons Math
>>> team doesn’t want then just get rid of it in your new version.
> 
> This option had been rejected in previous discussions, when I
> suggested that I would not release code that I could not
> maintain.
> 

Replace “I” with “we” and we are in agreement. It really isn’t all that 
important what one individual can or cannot do.

Ralph

Re: [VOTE] Release Apache Commons Weaver 1.3 based on RC1

[Matt Benson]

This vote is cancelled; I have found a problem with the release notes--they
were generated with the -SNAPSHOT version number embedded. RC2 forthcoming.

Matt

On Thu, Oct 13, 2016 at 3:08 PM, Matt Benson  wrote:

> I would like to release the [weaver] component.
>
> Apache Commons Weaver 1.3 RC1 is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16504).
>
> Maven artifacts are at:
>   https://repository.apache.org/content/repositories/orgapachecommons-1208
>  .
>
> Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
>
> The Subversion tag is:
>   http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.3_RC1
>  (r1764770).
>
> Site (note some links may be broken; this will be fixed when the site
> is deployed):
>   http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/index.html
>
> RAT Report:
>   http://people.apache.org/~mbenson/commons-weaver-1.3-rc1/rat-report.html
>
> Quality Reports (PMD/Checkstyle/Findbugs/japicmp):
>   http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc1/commons-weaver-parent/commons-weaver-processor/project-reports.html
>   http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc1/commons-weaver-parent/commons-weaver-modules-parent/
> commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-
> reports.html
>   http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc1/commons-weaver-parent/commons-weaver-modules-parent/
> commons-weaver-privilizer-parent/commons-weaver-
> privilizer/project-reports.html
>   http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc1/commons-weaver-parent/commons-weaver-modules-parent/
> commons-weaver-normalizer/project-reports.html
>   http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc1/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
>   http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc1/commons-weaver-parent/commons-weaver-antlib/project-reports.html
>
> Note that compatibility (japicmp) reports have only been produced for
> artifacts that could conceivably be used programmatically by downstream
> users: namely, *not* weaver modules.
>
> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now, i.e. after
> 2100UTC 16-October 2016
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>

Re: [VOTE] Release Apache Commons Weaver 1.3 based on RC2

[Gary Gregory]

Hi,

In the future, please do NOT delete a tag once a VOTE has been called.

Gary

On Thu, Oct 13, 2016 at 2:30 PM, Matt Benson  wrote:

> I would like to release the [weaver] component.
>
> Apache Commons Weaver 1.3 RC2 is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16517).
>
> Maven artifacts are at:
>   https://repository.apache.org/content/repositories/orgapachecommons-1210
> .
>
> Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
>
> The Subversion tag is:
>   http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.3_RC2
>  (r1764791).
>
> Site (note some links may be broken; this will be fixed when the site
> is deployed):
>   http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/index.html
>
> RAT Report:
>   http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/rat-report.html
>
> Quality Reports (PMD/Checkstyle/Findbugs/japicmp):
>
> http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc2/commons-weaver-parent/commons-weaver-modules-parent/
> commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-
> reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc2/commons-weaver-parent/commons-weaver-modules-parent/
> commons-weaver-privilizer-parent/commons-weaver-
> privilizer/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc2/commons-weaver-parent/commons-weaver-modules-parent/
> commons-weaver-normalizer/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.3-
> rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html
>
> Note that compatibility (japicmp) reports have only been produced for
> artifacts that could conceivably be used programmatically by downstream
> users: namely, *not* weaver modules.
>
> The only change from RC1 to RC2 has been the regeneration of the release
> notes.
>
> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now, i.e. after
> 2130UTC 16-October 2016
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Changes on the 3.x line

[Gilles]

On Thu, 13 Oct 2016 14:51:05 -0700, Ralph Goers wrote:
On Oct 13, 2016, at 10:50 AM, Gilles  
wrote:


On Thu, 13 Oct 2016 10:18:36 -0700, Gary Gregory wrote:
On Thu, Oct 13, 2016 at 9:13 AM, Ralph Goers 


wrote:



> On Oct 12, 2016, at 4:10 PM, Gilles 


wrote:
>
> IIRC, many PMC members did not "like" the idea of having more
> components.
> Even less so if those components are being extracted from 
Commons

> Math.
> The least "problematic" one, Commons RNG, barely collected the
> number of required votes for a release.
>
> Has that changed?
> Shall we request git repositories for the candidate components
> which I suggested back in May?


To be clear, Apache Commons currently lists about 40 sub-projects. 
These
projects are typically small and not closely related with any 
other

sub-project in any clear way.  The objection isn’t to adding more
sub-projects, it is to adding more sub-projects that seem related 
closely
enough that really belong together.  However, I don’t believe 
anyone

objected to Commons Math being a multi-module project.

I would object to creating new Commons components that are forked 
off from

Commons Math that have no maintainers.


It is "Commons Math" that does not have maintainers.

The new components, would, conspicuously, have maintainers.
That's one of the main arguments in favour of this option.


If there is code the Commons Math
team doesn’t want then just get rid of it in your new version.


This option had been rejected in previous discussions, when I
suggested that I would not release code that I could not
maintain.



Replace “I” with “we” and we are in agreement. It really isn’t all
that important what one individual can or cannot do.


I don't follow those statements at all.

*I* cannot speak for others; all I can say for sure is that *I*
would not release the whole of CM (be it 3 or 4) knowing full
well that there are whole swaths of code which nobody here can
maintain.[1]

And it seems that nobody else will do it either.

Hence, what is interesting to know is if you (each PMC member)
trust another PMC member (me) that says that the new components
would be maintained.

I also wrote several times why I think so.  [Where the opposite
argument ("CM is maintainable") is still false after 10 months
have elapsed.]

Quoting Jörg in an earlier post in this thread:
  "And most of us will agree that CM4 is dead."
[This is actually the first time it is acknowledged by someone
other than me.]

So the question is quite simple, synthetic and direct: Why
still oppose the creation of new components?


Gilles

[1] Because *I* consider it dishonest towards the potential
users. [We had a telling example with a requested
enhancement to the ODE functionality a few months ago.
Even in parts which I thought could still be maintained,
bugs turned out that are not easy to fix.]



Ralph



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

[VOTE] Release Apache Commons Weaver 1.3 based on RC2

[Matt Benson]

I would like to release the [weaver] component.

Apache Commons Weaver 1.3 RC2 is available for review at:
  https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16517).

Maven artifacts are at:
  https://repository.apache.org/content/repositories/orgapachecommons-1210 .

Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.

The Subversion tag is:
  http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.3_RC2
 (r1764791).

Site (note some links may be broken; this will be fixed when the site
is deployed):
  http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/index.html

RAT Report:
  http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/rat-report.html

Quality Reports (PMD/Checkstyle/Findbugs/japicmp):

http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.3-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html

Note that compatibility (japicmp) reports have only been produced for
artifacts that could conceivably be used programmatically by downstream
users: namely, *not* weaver modules.

The only change from RC1 to RC2 has been the regeneration of the release
notes.

Keys: https://dist.apache.org/repos/dist/release/commons/KEYS

Please review the release candidate and vote.
  This vote will close no sooner than 72 hours from now, i.e. after
2130UTC 16-October 2016

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

  Thanks!

Re: Commons CLI Nested Groups

[Gilles]

Hi.

On Thu, 13 Oct 2016 15:57:00 +0100, John Patrick wrote:

I've posted a message to the users list, but on reflecting I think
what I'm trying to achieve might be beyond commons-cli current
ability.

If I fork and work on adding nested OptionGroup's, would it stand a
change of being merged?
Is it a feature you want to support/provide?


Please describe what you propose in more details.



I want to check with dev's before wasting time on the potential 
feature...


Good precaution, indeed...

Regards,
Gilles



cheers,
John




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

[compress] Added in-memory support for zip and 7z

[Stefan Bodewig]

Hi all

actually it is SeekableByteChannel-support combined with a byte[] backed
implementation of SeekableByteChannel.

Over the past few days I've rewritten the zip and 7z packages to become
independent of RandomAccessFile and thus no longer require writing to or
reading from a file. The required changes haven't been big, but I'd
really like to have a few more eyes to validate what I've done.

I've also introduced SeekableInMemoryByteChannel (which might be a
candidate for commons-io or commons-nio but that's for a different
thread). This class currently clearly is not thread-safe and I'm leaning
towards just stating that it isn't and remove the half-hearted attempts
(volatile and local captures of changeable values) of making it look
thread-safe. The rest of Compress isn't thread-safe either.

I am aware that SeekableInMemoryByteChannel could use more tests.

Thoughts?

Stefan

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

Re: [Math] Changes on the 3.x line

[Gilles]

On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote:
On Oct 12, 2016 4:17 PM, "Gilles"  
wrote:


On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:


On Oct 12, 2016 3:34 PM, "Gilles"  
wrote:



On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:



Le 12/10/2016 à 18:45, Gilles a écrit :


So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.




To be clear, I have no plan to maintain CM 3. I applied a small 
bug fix
to CM 4, I just thought it would be nice to backport it if ever a 
new

CM

3 release is required. That's all.




That backport served as an example that could lead to a broader
reflection on the future of a project and the "community" around
it; but you ignored it, again, by expressly cutting that part of
my message.


I'm doing open source mostly for fun, my motivation is to help 
and make
something useful to others, and if a fixed CM 3 makes someone 
happy,

then so am I.




I am sad that those one-shots gives the false impression that
CM3 (or CM4) is alive.

Some people here could have the project to maintain CM3; even
if I'd prefer that they would work on CM4, they are of course
free to decide where they want to contribute.

However, I find it extremely uneasy that there is no roadmap
whatsoever; only criticism of what I proposed.

Is that fix worth a CM 3.7 release?
If not, and nobody works towards a release, what did the
reporter actually gain?



Sometimes, a user just wants a bug fix in an easy to apply release. 
The
liveliness of the project switches state as soon as the fix is 
delivered.
Release notes can warn that new features are only happening on the 
master

branch. If I get a bug fix I am happy ;-)



This is all fine, in "theory". But:
 * Who is going to _make_ a release for each applied patch?


Speaking here only about 3.x...

Whomever feels like it! :-) We do not have ownership as you well 
know. I do
not have a need for a patch today and I do not foresee needing one, 
but I

would certainly not be shy about cutting an RC if I needed one.


That's


 * Why this fix and not the other ones reported on JIRA?


It's up to the volunteer that steps up, with reasonable feedback from 
this

peanut gallery :-)


 * If a release should be considered only after all reported
   issues have been examined, who is going to do that work?


See above.



Where is the roadmap?


We do not need a roadmap for 3.x fixes IMO.

For 4.x, the answer is the same as it has always been, we discuss on 
the
ML. How else would it happen? At an Apache conference or meetup I 
suppose...


Gary


Gilles




Gary



What is the added value of this project if there is no
decision to move forward?
As I indicated a few months ago, the code sits there; and
the more time passes, the less it will attract new
contributors.


Gilles




Emmanuel Bourg






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

Re: [Math] Changes on the 3.x line

[Gilles]

On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote:
On Oct 12, 2016 4:17 PM, "Gilles"  
wrote:


On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote:


On Oct 12, 2016 3:34 PM, "Gilles"  
wrote:



On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote:



Le 12/10/2016 à 18:45, Gilles a écrit :


So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.




To be clear, I have no plan to maintain CM 3. I applied a small 
bug fix
to CM 4, I just thought it would be nice to backport it if ever a 
new

CM

3 release is required. That's all.




That backport served as an example that could lead to a broader
reflection on the future of a project and the "community" around
it; but you ignored it, again, by expressly cutting that part of
my message.


I'm doing open source mostly for fun, my motivation is to help 
and make
something useful to others, and if a fixed CM 3 makes someone 
happy,

then so am I.




I am sad that those one-shots gives the false impression that
CM3 (or CM4) is alive.

Some people here could have the project to maintain CM3; even
if I'd prefer that they would work on CM4, they are of course
free to decide where they want to contribute.

However, I find it extremely uneasy that there is no roadmap
whatsoever; only criticism of what I proposed.

Is that fix worth a CM 3.7 release?
If not, and nobody works towards a release, what did the
reporter actually gain?



Sometimes, a user just wants a bug fix in an easy to apply release. 
The
liveliness of the project switches state as soon as the fix is 
delivered.
Release notes can warn that new features are only happening on the 
master

branch. If I get a bug fix I am happy ;-)



This is all fine, in "theory". But:
 * Who is going to _make_ a release for each applied patch?


Speaking here only about 3.x...

Whomever feels like it! :-) We do not have ownership as you well 
know. I do
not have a need for a patch today and I do not foresee needing one, 
but I

would certainly not be shy about cutting an RC if I needed one.


Even if he wished to do it, the reporter and patch provider could
not do it (unless he is a committer already).

Will you grant the privilege on the basis of one patch?


 * Why this fix and not the other ones reported on JIRA?


It's up to the volunteer that steps up, with reasonable feedback from 
this

peanut gallery :-)


PMC members do not ask for feedback.
They do as they wish.
Usually, that's fine.
But in the case of a project that is in a bad situation like
CM (I call "bad", the shift from "bug report is handled within
hours" to "unmaintained"), it's not.


 * If a release should be considered only after all reported
   issues have been examined, who is going to do that work?


See above.


Well, the above is a non-answer.

No "privileged" developer is likely to spend his time doing
point releases.
So there should be a roadmap such as "new point release every
6 months, containing whatever has been fixed".

Otherwise, why would a contributor be motivated to provide a
patch?



Where is the roadmap?


We do not need a roadmap for 3.x fixes IMO.


I do not agree; I gave the reason above.

For 4.x, the answer is the same as it has always been, we discuss on 
the
ML. How else would it happen? At an Apache conference or meetup I 
suppose...


I've discussed a lot on the ML.
I've proposed things, and there has been no alternative (I do not
call letting the code rot, an alternative).

Don't you think that having maintained CM alone during 6 months
(from December to May) and, my stopping doing that have resulted
in nobody else doing it, is enough proof that the development
model is not good for this situation (big code, no team), and
that the "community" and PMC should support a radical change?

If not, it means that fairly soon, people will search for
alternative projects that are well maintained.

People who read this and have a certain competing project in
mind that has this property should say clearly that they in
fact support _that_ alternative.
All PMC members should indicate where they stand.


Gilles



Gary


Gilles




Gary



What is the added value of this project if there is no
decision to move forward?
As I indicated a few months ago, the code sits there; and
the more time passes, the less it will attract new
contributors.


Gilles




Emmanuel Bourg






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

Build failed in Jenkins: commons-jcs #177

[Apache Jenkins Server]

See 

Changes:

[tv] Replace SingleLinkedList with JDK ConcurrentLinkedQueue

--
[...truncated 931 lines...]
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPDiscoveryListenerUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/TestTCPLateralUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPConcurrentRandomTestUtil.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPFilterRemoveHashCodeUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/LateralTCPNoDeadLockConcurrentTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/lateral/socket/tcp/MockLateralCache.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/MockAuxiliaryCache.java
A commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/PurgatoryElementUnitTest.java
A 
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/HugeQuantityBlockDiskCacheLoadTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheCountUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheSteadyLoadTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheSizeUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheSameRegionConcurrentUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheRandomConcurrentTestUtil.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheConcurrentUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheUnitTestAbstract.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskElementDescriptorUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/block/BlockDiskCacheKeyStoreUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCSUnitTest.java
A 
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheConcurrentUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheKeyStoreUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheNoMemoryUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheConcurrentNoDeadLockUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheOptimizationUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheSteadyLoadTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexDiskCacheUnitTestAbstract.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheDefragPerformanceTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheSameRegionConcurrentUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/LRUMapSizeVsCount.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/DiskTestObjectUtil.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexDiskCacheCountUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/HugeQuantityIndDiskCacheLoadTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexDiskCacheSizeUnitTest.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/indexed/IndexedDiskCacheRandomConcurrentTestUtil.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/DiskTestObject.java
AU
commons-jcs-core/src/test/java/org/apache/commons/jcs/auxiliary/disk/AbstractDiskCacheUnitTest.java