Re: svn commit: r1747630 - in /commons/proper/jexl/trunk: RELEASE-NOTES.txt src/site/xdoc/changes.xml

[Gary Gregory]

Is that the proper default location for changes.xml? I thoughs it was in
src/changes?

Gary

On Thu, Jun 9, 2016 at 9:42 PM,  wrote:

> Author: henrib
> Date: Fri Jun 10 04:42:06 2016
> New Revision: 1747630
>
> URL: http://svn.apache.org/viewvc?rev=1747630=rev
> Log:
> JEXL:
> updated changes.xml & release-notes.txt
>
> Modified:
> commons/proper/jexl/trunk/RELEASE-NOTES.txt
> commons/proper/jexl/trunk/src/site/xdoc/changes.xml
>
> Modified: commons/proper/jexl/trunk/RELEASE-NOTES.txt
> URL:
> http://svn.apache.org/viewvc/commons/proper/jexl/trunk/RELEASE-NOTES.txt?rev=1747630=1747629=1747630=diff
>
> ==
> --- commons/proper/jexl/trunk/RELEASE-NOTES.txt (original)
> +++ commons/proper/jexl/trunk/RELEASE-NOTES.txt Fri Jun 10 04:42:06 2016
> @@ -28,7 +28,9 @@ Version 3.0.1 is a micro release to fix
>  Bugs Fixed in 3.0.1:
>  
>
> +* JEXL-198: JxltEngine Template does not expose pragmas
>  * JEXL-196: Script execution hangs while calling method with one
> argument without parameter
> +* JEXL-194  allow synchronization on iterableValue in foreach
> statement
>  * JEXL-195: Support for AtomicBoolean in logical expressions
>  * JEXL-193: InterruptedException is swallowed in function call in
> silent and non-strict mode
>  * JEXL-192: Invalid return type when expected result is null
>
> Modified: commons/proper/jexl/trunk/src/site/xdoc/changes.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/jexl/trunk/src/site/xdoc/changes.xml?rev=1747630=1747629=1747630=diff
>
> ==
> --- commons/proper/jexl/trunk/src/site/xdoc/changes.xml (original)
> +++ commons/proper/jexl/trunk/src/site/xdoc/changes.xml Fri Jun 10
> 04:42:06 2016
> @@ -26,12 +26,18 @@
>  
>  
>  
> + due-to="Terefang Verigorn">
> +JxltEngine Template does not expose pragmas
> +
>   due-to="Dmitri Blinov">
>  Script execution hangs while calling method with one
> argument without parameter
>  
>   due-to="Dmitri Blinov">
>  Support for AtomicBoolean in logical expressions
>  
> + due-to="Dmitri Blinov">
> +allow synchronization on iterableValue in foreach
> statement
> +
>   due-to="Dmitri Blinov">
>  InterruptedException is swallowed in function call in
> silent and non-strict mode
>  
>
>
>


-- 
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] Commons Math (r)evolution

[James Carman]

Exactly!
On Thu, Jun 9, 2016 at 10:54 PM Ralph Goers 
wrote:

> Given how few Math committees there are, that would require going into the
> incubator.
>
> Ralph
>
> > On Jun 9, 2016, at 6:24 PM, James Carman 
> wrote:
> >
> > TLP TLP TLP!
> >
> > You can split it up into whatever you want.
> >
> >> On Sun, Jun 5, 2016 at 8:49 PM Gilles 
> wrote:
> >>
> >> Hello.
> >>
> >> Commons Math as it was in the last official release (v3.6.1) and
> >> consequently as it is in the current development branch has
> >> become unmaintainable.
> >>
> >> This conclusion is unavoidable when looking at the following:
> >>  1. codebase statistics (as of today):
> >> * src/main/java   90834 lines of Java code (882 files)
> >> * src/test/java   95595 lines of Java code (552 files)
> >> * src/userguide/java   3493 lines of Java code (19 files)
> >>  2. number of posts on the "dev" ML (related to [Math]) in the
> >> last 2 months:
> >> * Gilles74
> >> * Artem Barger  20
> >> * sebb  15
> >> * Rob Tompkins   9
> >> * Eric Barnhill  7
> >> * 19 other people   46
> >>  3. development/maintenance activity in the last 4 months:
> >> * commits by Gilles  133
> >> * commits by others   12
> >>
> >> According to JIRA, among 180 issues currently targeted for the
> >> next major release (v4.0), 139 have been resolved (75 of which
> >> were not in v3.6.1).
> >>
> >> So, on the one hand, a lot of work has been done already, but
> >> on the other, a lot remains.
> >> Some issues have been pending for several years, in particular
> >> those that required a major refactoring (e.g. in the packages
> >> "o.a.c.m.linear" and "o.a.c.m.optim").
> >>
> >> The remaining work is unlikely to be completed soon since the
> >> fork of Commons Math has drastically reduced the development
> >> capacity.
> >>
> >> Moreover, as whole areas of the codebase have become in effect
> >> unsupported, it would be deceiving to release a version 4.0 of
> >> Commons Math that would include all of it.
> >>
> >> Of course, anyone who wishes to maintain some of these codes
> >> (answer user questions, fix bugs, create enhancements, etc.)
> >> is most welcome to step forward.
> >>
> >> But I'm not optimistic that the necessary level of support can
> >> be achieved in the near future for all the codebase.
> >> Waiting for that to happen would entail that code that could
> >> be in a releasable state soon will be on hold for an indefinite
> >> time.
> >>
> >> The purpose of this post is to initiate a discussion about
> >> splitting Commons Math, along the following lines:
> >> 1. Identify independent functionality that can be maintained
> >>even by a small (even a 1-person) team within Commons and
> >>make it a new component.
> >> 2. Identify functionality that cannot be maintained anymore
> >>inside Commons and try to reach out to users of this
> >>functionality, asking whether they would be willing to
> >>give a helping hand.
> >>If there is sufficient interest, and a new development
> >>team can form, that code would then be transferred to the
> >>Apache "incubator".
> >>
> >> There are numerous advantages to having separate components
> >> rather than a monolithic library:
> >>  * Limited and well-defined scope
> >>  * Immediate visibility of purpose
> >>  * Lower barrier to entry
> >>  * Independent development policy
> >>  * Homogeneous codebase
> >>  * Independent release schedule
> >>  * Foster a new community around the component
> >>
> >> According to the most recent development activity, the likely
> >> candidates for becoming a new component are:
> >>  * Pseudo-random numbers generators (package "o.a.c.m.rng")
> >>  * Complex numbers (package "o.a.c.m.complex")
> >>  * Clustering algorithms (package "o.a.c.m.ml.clustering")
> >>
> >> Other potential candidates:
> >>  * "FastMath" (which should be renamed to something like
> >>"AccurateMath", cf. reports about slowness of some of
> >>the functions)
> >>  * Special functions (package "o.a.c.m.special")
> >>  * Selected "utilities" (package "o.a.c.m.util")
> >>
> >>
> >> Best regards,
> >> Gilles
> >>
> >>
> >> -
> >> 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: [Math] Commons Math (r)evolution

[Ralph Goers]

Given how few Math committees there are, that would require going into the 
incubator.

Ralph

> On Jun 9, 2016, at 6:24 PM, James Carman  wrote:
> 
> TLP TLP TLP!
> 
> You can split it up into whatever you want.
> 
>> On Sun, Jun 5, 2016 at 8:49 PM Gilles  wrote:
>> 
>> Hello.
>> 
>> Commons Math as it was in the last official release (v3.6.1) and
>> consequently as it is in the current development branch has
>> become unmaintainable.
>> 
>> This conclusion is unavoidable when looking at the following:
>>  1. codebase statistics (as of today):
>> * src/main/java   90834 lines of Java code (882 files)
>> * src/test/java   95595 lines of Java code (552 files)
>> * src/userguide/java   3493 lines of Java code (19 files)
>>  2. number of posts on the "dev" ML (related to [Math]) in the
>> last 2 months:
>> * Gilles74
>> * Artem Barger  20
>> * sebb  15
>> * Rob Tompkins   9
>> * Eric Barnhill  7
>> * 19 other people   46
>>  3. development/maintenance activity in the last 4 months:
>> * commits by Gilles  133
>> * commits by others   12
>> 
>> According to JIRA, among 180 issues currently targeted for the
>> next major release (v4.0), 139 have been resolved (75 of which
>> were not in v3.6.1).
>> 
>> So, on the one hand, a lot of work has been done already, but
>> on the other, a lot remains.
>> Some issues have been pending for several years, in particular
>> those that required a major refactoring (e.g. in the packages
>> "o.a.c.m.linear" and "o.a.c.m.optim").
>> 
>> The remaining work is unlikely to be completed soon since the
>> fork of Commons Math has drastically reduced the development
>> capacity.
>> 
>> Moreover, as whole areas of the codebase have become in effect
>> unsupported, it would be deceiving to release a version 4.0 of
>> Commons Math that would include all of it.
>> 
>> Of course, anyone who wishes to maintain some of these codes
>> (answer user questions, fix bugs, create enhancements, etc.)
>> is most welcome to step forward.
>> 
>> But I'm not optimistic that the necessary level of support can
>> be achieved in the near future for all the codebase.
>> Waiting for that to happen would entail that code that could
>> be in a releasable state soon will be on hold for an indefinite
>> time.
>> 
>> The purpose of this post is to initiate a discussion about
>> splitting Commons Math, along the following lines:
>> 1. Identify independent functionality that can be maintained
>>even by a small (even a 1-person) team within Commons and
>>make it a new component.
>> 2. Identify functionality that cannot be maintained anymore
>>inside Commons and try to reach out to users of this
>>functionality, asking whether they would be willing to
>>give a helping hand.
>>If there is sufficient interest, and a new development
>>team can form, that code would then be transferred to the
>>Apache "incubator".
>> 
>> There are numerous advantages to having separate components
>> rather than a monolithic library:
>>  * Limited and well-defined scope
>>  * Immediate visibility of purpose
>>  * Lower barrier to entry
>>  * Independent development policy
>>  * Homogeneous codebase
>>  * Independent release schedule
>>  * Foster a new community around the component
>> 
>> According to the most recent development activity, the likely
>> candidates for becoming a new component are:
>>  * Pseudo-random numbers generators (package "o.a.c.m.rng")
>>  * Complex numbers (package "o.a.c.m.complex")
>>  * Clustering algorithms (package "o.a.c.m.ml.clustering")
>> 
>> Other potential candidates:
>>  * "FastMath" (which should be renamed to something like
>>"AccurateMath", cf. reports about slowness of some of
>>the functions)
>>  * Special functions (package "o.a.c.m.special")
>>  * Selected "utilities" (package "o.a.c.m.util")
>> 
>> 
>> Best regards,
>> Gilles
>> 
>> 
>> -
>> 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: [Math] Commons Math (r)evolution

[James Carman]

TLP TLP TLP!

You can split it up into whatever you want.

On Sun, Jun 5, 2016 at 8:49 PM Gilles  wrote:

> Hello.
>
> Commons Math as it was in the last official release (v3.6.1) and
> consequently as it is in the current development branch has
> become unmaintainable.
>
> This conclusion is unavoidable when looking at the following:
>   1. codebase statistics (as of today):
>  * src/main/java   90834 lines of Java code (882 files)
>  * src/test/java   95595 lines of Java code (552 files)
>  * src/userguide/java   3493 lines of Java code (19 files)
>   2. number of posts on the "dev" ML (related to [Math]) in the
>  last 2 months:
>  * Gilles74
>  * Artem Barger  20
>  * sebb  15
>  * Rob Tompkins   9
>  * Eric Barnhill  7
>  * 19 other people   46
>   3. development/maintenance activity in the last 4 months:
>  * commits by Gilles  133
>  * commits by others   12
>
> According to JIRA, among 180 issues currently targeted for the
> next major release (v4.0), 139 have been resolved (75 of which
> were not in v3.6.1).
>
> So, on the one hand, a lot of work has been done already, but
> on the other, a lot remains.
> Some issues have been pending for several years, in particular
> those that required a major refactoring (e.g. in the packages
> "o.a.c.m.linear" and "o.a.c.m.optim").
>
> The remaining work is unlikely to be completed soon since the
> fork of Commons Math has drastically reduced the development
> capacity.
>
> Moreover, as whole areas of the codebase have become in effect
> unsupported, it would be deceiving to release a version 4.0 of
> Commons Math that would include all of it.
>
> Of course, anyone who wishes to maintain some of these codes
> (answer user questions, fix bugs, create enhancements, etc.)
> is most welcome to step forward.
>
> But I'm not optimistic that the necessary level of support can
> be achieved in the near future for all the codebase.
> Waiting for that to happen would entail that code that could
> be in a releasable state soon will be on hold for an indefinite
> time.
>
> The purpose of this post is to initiate a discussion about
> splitting Commons Math, along the following lines:
> 1. Identify independent functionality that can be maintained
> even by a small (even a 1-person) team within Commons and
> make it a new component.
> 2. Identify functionality that cannot be maintained anymore
> inside Commons and try to reach out to users of this
> functionality, asking whether they would be willing to
> give a helping hand.
> If there is sufficient interest, and a new development
> team can form, that code would then be transferred to the
> Apache "incubator".
>
> There are numerous advantages to having separate components
> rather than a monolithic library:
>   * Limited and well-defined scope
>   * Immediate visibility of purpose
>   * Lower barrier to entry
>   * Independent development policy
>   * Homogeneous codebase
>   * Independent release schedule
>   * Foster a new community around the component
>
> According to the most recent development activity, the likely
> candidates for becoming a new component are:
>   * Pseudo-random numbers generators (package "o.a.c.m.rng")
>   * Complex numbers (package "o.a.c.m.complex")
>   * Clustering algorithms (package "o.a.c.m.ml.clustering")
>
> Other potential candidates:
>   * "FastMath" (which should be renamed to something like
> "AccurateMath", cf. reports about slowness of some of
> the functions)
>   * Special functions (package "o.a.c.m.special")
>   * Selected "utilities" (package "o.a.c.m.util")
>
>
> Best regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

+1. (Or -1, depending on which way you want to look at it). 

Ralph

> On Jun 9, 2016, at 4:48 PM, Jörg Schaible  wrote:
> 
> Hi Gilles,
> 
> Gilles wrote:
> 
> [snip]
> 
>> _Some_ developer(s) should be able to support whatever is in
>> development.
>> Otherwise how can it be deemed "in development"?
>> 
>> Just today, two issues were reported on JIRA:
>>   https://issues.apache.org/jira/browse/MATH-172
>>   https://issues.apache.org/jira/browse/MATH-1375
>> 
>> They, unfortunately, illustrate my point.
> 
> No, it does not.
> 
> MATH-172 is about an enhancement. Unfortunately no-one can currently 
> implement it, so we have to wait until someone can or the issue stays simply 
> unresolved again. You've requested for help and that was the proper action. 
> However, there has been no problem to release 3.0 in this state, so why 
> should it be a problem now for 4.0?
> 
> MATH-1735 is a bug report for a problem which is currently not reproducible. 
> Again you did the right action, but without more input and without a 
> possibility to reproduce the problem, there's not much we can do. Again, why 
> should this issue prevent a release of 4.0?
> 
>> Moreover what could be true for VFS is not for CM where there are many,
>> many different areas that have nothing in common (except perhaps some
>> ubiquitous very-low utilities which might be worth their own component
>> to serve as a, maybe "internal", dependency).
>> 
>> Also, compare the source basic statistics (lines of code):
>>   VFS  CM
>> Java code24215   90834
>> Unit tests8926   95595
>> 
>> All in all, CM is more than 5 times larger than VFS (not even counting
>> documentation).
> 
> Any why is size suddenly a problem?
> 
> [snip]
> 
 That's why I strongly favour cutting this monolith into pieces
 with a limited scope.
>>> 
>>> Nobody objects, but if you look at vfs, it is still *one* Apache
>>> Commons
>>> component, just with multiple artifacts. All these artifacts are
>>> released
>>> *together*.
>> 
>> Sorry I'm lost, I looked there:
>>   http://commons.apache.org/proper/commons-vfs/download_vfs.cgi
>> 
>> And, it seems that all the functionality is in a single JAR.
>> [Other files contain the sources, tests, examples.]
> 
> Then look at commons-weaver.
> 
>> Anyways, it is obvious that, in VFS, there is a well defined scope
>> (a unifying rationale).
>> 
>> No such thing in CM.
>> 
>> What I want to achieve is indeed to create a set of components that are
>> more like VFS!
> 
> Fine. But talk about artifacts, not components. Apache Commons Math is still 
> *one* component of Apache Commons. It does not matter if you divide the code 
> into different artifacts as long as anything is released together. 
> Individual release cycles for the different parts can only happen if Math is 
> TLP, but not in Apache Commons. We will certainly not allow and create again 
> any sub-umbrellas (search the Jakarta archives).
> 
>> This is particularly obvious with the RNGs where there is one unifying
>> interface, a factory method and multiple implementations.
>> [Of course, in that case, the new component will be much simpler than
>> VFS (which is a "good thing", isn't it?).]
>> 
>>> Turning math into a multi-project has nothing to do with your
>>> plans to drop mature code,
>> 
>> I am not dropping anything (others did that); I am stating facts and I
>> now want to spend my time on something (hopefully) worth it.  [Working
>> to modularize unsupported code is a (huge) waste of time.]
>> 
>> Also, in the case of CM, "mature code" is meaningless as an overall
>> qualifier: some codes are
>>  * new (and never released, e.g. 64-bits-based RNGs)
>>  * algorithms introduced relatively recently (and perhaps never used)
>>  * old (and sometimes outdated and impossible to fix without breaking
>>compatibility)
>>  * mostly functional (but impossible to maintain, cf. MATH-1375)
>>  * resulting from a refactoring (hence even when the functionality has
>>existed for a long time, the code is not "mature")
>> 
>> IMHO, maturity should be visible in the code.  It's an impression that
>> builds up by looking at the code as a whole, and coming to the
>> conclusion
>> that indeed there is some overall consistency across files and
>> packages.
>> 
>> Within some CM packages: yes (even if "mature" would certainly not mean
>> free of sometimes serious problems).
>> 
>> Across the whole library: certainly *not*.
>> [For reasons I could expand on.  But I did several times (cf. archives)
>> without succeeding in changing course.]
>> 
>>> because you (and currently no-one else) cannot
>>> answer questions to its functionality.
>> 
>> See the first post in this thread, in the part about gradually
>> re-adding
>> codes if and when they are supported by a new team.
> 
> What you talk about is a complete new component without a proper upgrade 
> path for users of Math 3.x. You wanna use the new stuff for complex numbers? 
> 

Re: [crypto] Logging dependency

[James Carman]

I'll check it out. The printf sounds nice
On Thu, Jun 9, 2016 at 7:18 PM Ralph Goers 
wrote:

>
> > On Jun 9, 2016, at 3:55 PM, James Carman 
> wrote:
> >
> > On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker  wrote:
> >
> >> There is a huge list of advantages to using log4j-api over slf4j-api
> >> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> >> unless the competition is clearly better for the use case (like using
> Jetty
> >> instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
> >> works fine with logback as well, so it's not like it prevents people
> from
> >> using slf4j bindings at runtime.
> >>
> >>
> > It's just my personal preference.  I have grown used to it and use it so
> > much.  In Karaf (where I spend most of my time these days), I don't even
> > have to think about it.
>
> That is understandable. But you should really compare the APIs. Just as
> SLF4J is much better than Commons Logging, so too is Log4j’s API much
> better than SLF4J’s - at least in the opinion of those who develop Log4j.
>
> Also, SLF4J advertises 2 key features - parameterized log statements and
> Markers.  However, SLF4J markers are a mess. The code isn’t thread safe and
> has terrible performance (which you can see on the Log4j performance page).
> Log4j also supports parameterized logging, but it also supports using
> printf style strings, MessageFormat strings as well as logging Messages
> instead of Strings. And, of course, it supports Lamda’s, which goes even
> further into not needing to wrap logging statements in if isEnabled checks.
>
> And as Gary mentioned, we intentionally created a bridge from Log4j’s API
> to SLF4J for those who want to use some other implementation.
>
> Ralph
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Commons Math (r)evolution

[Jörg Schaible]

Hi Gilles,

Gilles wrote:

[snip]

> _Some_ developer(s) should be able to support whatever is in
> development.
> Otherwise how can it be deemed "in development"?
> 
> Just today, two issues were reported on JIRA:
>https://issues.apache.org/jira/browse/MATH-172
>https://issues.apache.org/jira/browse/MATH-1375
> 
> They, unfortunately, illustrate my point.

No, it does not.

MATH-172 is about an enhancement. Unfortunately no-one can currently 
implement it, so we have to wait until someone can or the issue stays simply 
unresolved again. You've requested for help and that was the proper action. 
However, there has been no problem to release 3.0 in this state, so why 
should it be a problem now for 4.0?

MATH-1735 is a bug report for a problem which is currently not reproducible. 
Again you did the right action, but without more input and without a 
possibility to reproduce the problem, there's not much we can do. Again, why 
should this issue prevent a release of 4.0?

> Moreover what could be true for VFS is not for CM where there are many,
> many different areas that have nothing in common (except perhaps some
> ubiquitous very-low utilities which might be worth their own component
> to serve as a, maybe "internal", dependency).
> 
> Also, compare the source basic statistics (lines of code):
>VFS  CM
> Java code24215   90834
> Unit tests8926   95595
> 
> All in all, CM is more than 5 times larger than VFS (not even counting
> documentation).

Any why is size suddenly a problem?

[snip]

>>> That's why I strongly favour cutting this monolith into pieces
>>> with a limited scope.
>>
>> Nobody objects, but if you look at vfs, it is still *one* Apache
>> Commons
>> component, just with multiple artifacts. All these artifacts are
>> released
>> *together*.
> 
> Sorry I'm lost, I looked there:
>http://commons.apache.org/proper/commons-vfs/download_vfs.cgi
> 
> And, it seems that all the functionality is in a single JAR.
> [Other files contain the sources, tests, examples.]

Then look at commons-weaver.

> Anyways, it is obvious that, in VFS, there is a well defined scope
> (a unifying rationale).
> 
> No such thing in CM.
> 
> What I want to achieve is indeed to create a set of components that are
> more like VFS!

Fine. But talk about artifacts, not components. Apache Commons Math is still 
*one* component of Apache Commons. It does not matter if you divide the code 
into different artifacts as long as anything is released together. 
Individual release cycles for the different parts can only happen if Math is 
TLP, but not in Apache Commons. We will certainly not allow and create again 
any sub-umbrellas (search the Jakarta archives).

> This is particularly obvious with the RNGs where there is one unifying
> interface, a factory method and multiple implementations.
> [Of course, in that case, the new component will be much simpler than
> VFS (which is a "good thing", isn't it?).]
> 
>> Turning math into a multi-project has nothing to do with your
>> plans to drop mature code,
> 
> I am not dropping anything (others did that); I am stating facts and I
> now want to spend my time on something (hopefully) worth it.  [Working
> to modularize unsupported code is a (huge) waste of time.]
> 
> Also, in the case of CM, "mature code" is meaningless as an overall
> qualifier: some codes are
>   * new (and never released, e.g. 64-bits-based RNGs)
>   * algorithms introduced relatively recently (and perhaps never used)
>   * old (and sometimes outdated and impossible to fix without breaking
> compatibility)
>   * mostly functional (but impossible to maintain, cf. MATH-1375)
>   * resulting from a refactoring (hence even when the functionality has
> existed for a long time, the code is not "mature")
> 
> IMHO, maturity should be visible in the code.  It's an impression that
> builds up by looking at the code as a whole, and coming to the
> conclusion
> that indeed there is some overall consistency across files and
> packages.
> 
> Within some CM packages: yes (even if "mature" would certainly not mean
> free of sometimes serious problems).
> 
> Across the whole library: certainly *not*.
> [For reasons I could expand on.  But I did several times (cf. archives)
> without succeeding in changing course.]
> 
>> because you (and currently no-one else) cannot
>> answer questions to its functionality.
> 
> See the first post in this thread, in the part about gradually
> re-adding
> codes if and when they are supported by a new team.

What you talk about is a complete new component without a proper upgrade 
path for users of Math 3.x. You wanna use the new stuff for complex numbers? 
Well, adjust your code to the new structures in commons-math-complex-4.0. 
Oh, you also want to use genetic algorithms?, Well, that part of the code 
should stick with commons-math-3.0, because we did not took it over for 4.0. 
Maybe for 4.1 ...

Sorry, but for such a release I already propose my vote 

Re: [imaging] Loggging (again)

[Matt Sicker]

+1 on log4j-api

On 9 June 2016 at 18:08, Gary Gregory  wrote:

> It's a recurring theme ([crypto]).
>
> [imaging] has cobbled up it's own mini-logging
> framework: org.apache.commons.imaging.util.Debug
>
> I suggest we rip it out or replace it with Log4j 2's log4-api.
>
> Gary
>
> --
> 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
>



-- 
Matt Sicker 

Re: [crypto] Logging dependency

[Ralph Goers]

> On Jun 9, 2016, at 3:55 PM, James Carman  wrote:
> 
> On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker  wrote:
> 
>> There is a huge list of advantages to using log4j-api over slf4j-api
>> nowadays, plus I do prefer to use Apache dependencies in Apache projects
>> unless the competition is clearly better for the use case (like using Jetty
>> instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
>> works fine with logback as well, so it's not like it prevents people from
>> using slf4j bindings at runtime.
>> 
>> 
> It's just my personal preference.  I have grown used to it and use it so
> much.  In Karaf (where I spend most of my time these days), I don't even
> have to think about it.

That is understandable. But you should really compare the APIs. Just as SLF4J 
is much better than Commons Logging, so too is Log4j’s API much better than 
SLF4J’s - at least in the opinion of those who develop Log4j. 

Also, SLF4J advertises 2 key features - parameterized log statements and 
Markers.  However, SLF4J markers are a mess. The code isn’t thread safe and has 
terrible performance (which you can see on the Log4j performance page). Log4j 
also supports parameterized logging, but it also supports using printf style 
strings, MessageFormat strings as well as logging Messages instead of Strings. 
And, of course, it supports Lamda’s, which goes even further into not needing 
to wrap logging statements in if isEnabled checks.

And as Gary mentioned, we intentionally created a bridge from Log4j’s API to 
SLF4J for those who want to use some other implementation.

Ralph



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

[imaging] Loggging (again)

[Gary Gregory]

It's a recurring theme ([crypto]).

[imaging] has cobbled up it's own mini-logging
framework: org.apache.commons.imaging.util.Debug

I suggest we rip it out or replace it with Log4j 2's log4-api.

Gary

-- 
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] Commons Math (r)evolution

[Gilles]

On Thu, 9 Jun 2016 14:53:20 -0700, Ralph Goers wrote:
On Jun 9, 2016, at 2:12 PM, Gilles  
wrote:


Hello Jörg.

On Thu, 09 Jun 2016 09:43:06 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:


Hi.

On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:

On Wed, Jun 8, 2016 at 12:25 AM, Gilles

wrote:



According to JIRA, among 180 issues currently targeted for the

next major release (v4.0), 139 have been resolved (75 of which
were not in v3.6.1).



​Huh, it's above of 75% completion :)​



Everybody is welcome to review the "open" issues and comment
about them.



​I guess someone need to prioritize them​ according to they
importance for
release.


Importance is relative... :-}

IMO, it is important to not release unsupported code.


Unit test *are* kind of support.


Unit tests are not what I mean by "support".  They only increase the
probability that the code behaves as expected. [And sometimes they 
do

not because they can be buggy too, as I discovered when refactoring
the "random" package.]


Now that is a funny argument.  If you can write a proper unit test
for the code typically you understand what the code is doing and 
could

fix it if needed.


Yes.  Where did I say otherwise?



But anyways, my reservations have nothing to do with the 
functionality
of released code: users who are satisfied with the service provided 
by
v3.6.1 (or any of the previous versions of CM) have no reason to 
upgrade

to 4.0.  [By upgrading, all they get is the obligation to change the
"import" statements.]

And we have no reason to release a v4.0 of a code that
1. has not changed
2. is not supported


What you seem to be proposing is tossing code that “isn’t supported”
even if it works just fine. I don’t understand why you would want to
do that.


No, you misunderstood: I want to work on, and release, code which we
can support.
Code which we can't support will stay in the "develop" branch until
someone feels confident to release it.


What I am seeing here is a bunch of people coming on board who seem
to really want to help and get involved. Before doing radical things
like dumping a large portion of the code base please take the time to
see how things play out.


I did take the time (and I'm not going to continue wasting my time the
way I did all these years).

I just gave two examples of unsolvable issues due to code being
unsupported.  Please let us know how you'd handle them.

Also, to conclude a discussion that go in circles: I'm not preventing
(how could I?) you to release CM v4.0 with whatever contents you see
fit.
I gave my arguments for discouraging such a step and others in favour
of my preferred alternative, which I'd like to start working on,
concretely, in order to see how it'll play out indeed.

Gilles


Ralph



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

Re: [crypto] Logging dependency

[James Carman]

On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker  wrote:

> There is a huge list of advantages to using log4j-api over slf4j-api
> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> unless the competition is clearly better for the use case (like using Jetty
> instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
> works fine with logback as well, so it's not like it prevents people from
> using slf4j bindings at runtime.
>
>
It's just my personal preference.  I have grown used to it and use it so
much.  In Karaf (where I spend most of my time these days), I don't even
have to think about it.

Re: [Math] Commons Math (r)evolution

[Gilles]

Hi.

On Thu, 9 Jun 2016 18:02:49 +0300, Artem Barger wrote:

On Thu, Jun 9, 2016 at 1:54 AM, Gilles 
wrote:

​I guess someone need to prioritize them​ according to they 
importance for



release.



Importance is relative... :-}



​Indeed it's very objective function,  however someone has to decide
where to focus.​


Please list the alternatives, and I will let you know what are my
preferences.
But anyone can decide what he will do or not...


IMO, it is important to not release unsupported code.
So the priority would be higher for issues that would be included
in the release of the new Commons components.
Hence the need to figure out what these components will be.



​Not clear whenever you really mean by not releasing unsupported code 
is
to exclude already existing parts which doesn't anyone who will be 
capable

to maintain the functionality and solve possible bugs?​


I did not understand this sentence, sorry. :-}




Which ones?

​I will look into JIRA and provide the issue numbers, and of 
course I

can cover and assist with ML part and particular clustering.​



Thanks.



​You are welcome :)
So I looked through some of the open issues and I have a couple of
questions them​:

1. Which affected version do I really need to consider as an 
important to

be released in the next version?


It depends what is the contents of the release.
Certainly (IMO), issues in classes that are not going to be released 
any

time soon, are low priority.


2. I've looked into affected versions: 3.5, 3.6, 3.6.1, 3.7 and 4.0.
Overall found
something like ~25 open bugs/issues. What about issues opened for 
lower

releases?


Theses are probably the hardest to fix (often it relates to the
refactoring of whole packages like e.g. MATH-756).

As I've argued in this thread, my preference is to focus on extracting
independent functionalities and turn them into new components.

The point is not to about making negative choices (a.k.a. "dropping 
code")
but making positive choices as to what you'd include in a given 
component.



For example while I'm looking into MATH-1329
, it sounds not 
really

hard to have it fixed,
but looking on it not sure whenever it was accepted and approved as
something that need
to be done.

Next MATH-1315  
seems like

reported has provided the patch and the only thing
missing is unit test, will addition of unit tests help to make that 
one

resolved?

MATH-1284  here is 
not

clear what is the final decision, according to comments look
like it can be resolved.

Here MATH-1262  
according

to the comments editing current javadoc to explain the limitation
should also rest this case, am I missing something?

I think I can help to handle MATH-1281
, right after I will
finish the refactoring and
optimizations for kmeans clustering.


[Please start a new thread for each of the specific issues above.
This list holds many conversations at the same time, and if multiple
subject are handled within a single thread, it quickly becomes
impossible to follow.  Thanks!]

​Listed issues/tickets where I can help to provide support or fix, 
most

likely missed something
but can start with these.​


It's up to you really which concrete issues you want to fix.

with additional functionality, since I think I can provide my code 
for

several classification
algorithms​.



That sounds nice.
Which algorithms?


​Naive Bayes, kNN, Decision Trees, Random Forest. I guess adding 
these into

the project will require
serious redesign of ML package​.


Again, up to you to propose something new. :-)
IMHO, it is extremely important to have a clean design, and clear goals
(e.g. support for parallel computing).


Regards,
Gilles


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

Re: [Math] Commons Math (r)evolution

[Gary Gregory]

On Thu, Jun 9, 2016 at 2:53 PM, Ralph Goers 
wrote:

>
> > On Jun 9, 2016, at 2:12 PM, Gilles  wrote:
> >
> > Hello Jörg.
> >
> > On Thu, 09 Jun 2016 09:43:06 +0200, Jörg Schaible wrote:
> >> Hi Gilles,
> >>
> >> Gilles wrote:
> >>
> >>> Hi.
> >>>
> >>> On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:
>  On Wed, Jun 8, 2016 at 12:25 AM, Gilles
>  
>  wrote:
> 
> >
> > According to JIRA, among 180 issues currently targeted for the
> >>> next major release (v4.0), 139 have been resolved (75 of which
> >>> were not in v3.6.1).
> >>>
> >>>
> >> ​Huh, it's above of 75% completion :)​
> >>
> >
> > Everybody is welcome to review the "open" issues and comment
> > about them.
> >
> >
>  ​I guess someone need to prioritize them​ according to they
>  importance for
>  release.
> >>>
> >>> Importance is relative... :-}
> >>>
> >>> IMO, it is important to not release unsupported code.
> >>
> >> Unit test *are* kind of support.
> >
> > Unit tests are not what I mean by "support".  They only increase the
> > probability that the code behaves as expected. [And sometimes they do
> > not because they can be buggy too, as I discovered when refactoring
> > the "random" package.]
>
> Now that is a funny argument.  If you can write a proper unit test for the
> code typically you understand what the code is doing and could fix it if
> needed.
>
> >
> > But anyways, my reservations have nothing to do with the functionality
> > of released code: users who are satisfied with the service provided by
> > v3.6.1 (or any of the previous versions of CM) have no reason to upgrade
> > to 4.0.  [By upgrading, all they get is the obligation to change the
> > "import" statements.]
> >
> > And we have no reason to release a v4.0 of a code that
> > 1. has not changed
> > 2. is not supported
>
> What you seem to be proposing is tossing code that “isn’t supported” even
> if it works just fine. I don’t understand why you would want to do that.
>
> What I am seeing here is a bunch of people coming on board who seem to
> really want to help and get involved. Before doing radical things like
> dumping a large portion of the code base please take the time to see how
> things play out.
>

+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

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

> On Jun 9, 2016, at 2:12 PM, Gilles  wrote:
> 
> Hello Jörg.
> 
> On Thu, 09 Jun 2016 09:43:06 +0200, Jörg Schaible wrote:
>> Hi Gilles,
>> 
>> Gilles wrote:
>> 
>>> Hi.
>>> 
>>> On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:
 On Wed, Jun 8, 2016 at 12:25 AM, Gilles
 
 wrote:
 
> 
> According to JIRA, among 180 issues currently targeted for the
>>> next major release (v4.0), 139 have been resolved (75 of which
>>> were not in v3.6.1).
>>> 
>>> 
>> ​Huh, it's above of 75% completion :)​
>> 
> 
> Everybody is welcome to review the "open" issues and comment
> about them.
> 
> 
 ​I guess someone need to prioritize them​ according to they
 importance for
 release.
>>> 
>>> Importance is relative... :-}
>>> 
>>> IMO, it is important to not release unsupported code.
>> 
>> Unit test *are* kind of support.
> 
> Unit tests are not what I mean by "support".  They only increase the
> probability that the code behaves as expected. [And sometimes they do
> not because they can be buggy too, as I discovered when refactoring
> the "random" package.]

Now that is a funny argument.  If you can write a proper unit test for the code 
typically you understand what the code is doing and could fix it if needed. 

> 
> But anyways, my reservations have nothing to do with the functionality
> of released code: users who are satisfied with the service provided by
> v3.6.1 (or any of the previous versions of CM) have no reason to upgrade
> to 4.0.  [By upgrading, all they get is the obligation to change the
> "import" statements.]
> 
> And we have no reason to release a v4.0 of a code that
> 1. has not changed
> 2. is not supported

What you seem to be proposing is tossing code that “isn’t supported” even if it 
works just fine. I don’t understand why you would want to do that.  

What I am seeing here is a bunch of people coming on board who seem to really 
want to help and get involved. Before doing radical things like dumping a large 
portion of the code base please take the time to see how things play out.

Ralph

Jenkins build is back to normal : Commons-Compress #114

[Apache Jenkins Server]

See 


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

Re: [Math] Commons Math (r)evolution

[Gilles]

Hello Jörg.

On Thu, 09 Jun 2016 09:43:06 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:


Hi.

On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:

On Wed, Jun 8, 2016 at 12:25 AM, Gilles

wrote:



According to JIRA, among 180 issues currently targeted for the

next major release (v4.0), 139 have been resolved (75 of which
were not in v3.6.1).



​Huh, it's above of 75% completion :)​



Everybody is welcome to review the "open" issues and comment
about them.



​I guess someone need to prioritize them​ according to they
importance for
release.


Importance is relative... :-}

IMO, it is important to not release unsupported code.


Unit test *are* kind of support.


Unit tests are not what I mean by "support".  They only increase the
probability that the code behaves as expected. [And sometimes they do
not because they can be buggy too, as I discovered when refactoring
the "random" package.]

But anyways, my reservations have nothing to do with the functionality
of released code: users who are satisfied with the service provided by
v3.6.1 (or any of the previous versions of CM) have no reason to 
upgrade

to 4.0.  [By upgrading, all they get is the obligation to change the
"import" statements.]

And we have no reason to release a v4.0 of a code that
 1. has not changed
 2. is not supported


So the priority would be higher for issues that would be included
in the release of the new Commons components.
Hence the need to figure out what these components will be.


Of course, anyone who wishes to maintain some of these codes

(answer user questions, fix bugs, create enhancements, etc.)
is most welcome to step forward.



​I can try to cover some of these and maintain relevant code
parts.​



Which ones?

​I will look into JIRA and provide the issue numbers, and of course 
I

can cover and assist with ML part and particular clustering.​


Thanks.



IMO, a maintainer is someone who is able to respond to user
questions and to figure out whether a bug report is valid.



​I'm subscribed for mailing list for quite a while and haven't
seen a lot of questions coming from user​s.


The "user" ML has always been fairly quiet.
Does it mean that the code is really easy to use?
Or feature-complete (I doubt that)?
Or that there are very few users for the most complex features?

The "dev" ML was usually (much) more active.

The point is that when someone asks a question or propose an
contribution, there must be someone to answer.


And this is IMHO a wrong assumption. We have a lot of components 
where the

original authors have left long ago. So the situation is not new.


Having no support is bad (IMO).
[It doesn't have to be from the original authors of course.]

Math is a specialized library and nobody expects that it is 
accompanied by
tutorials explaining the theory or developers that act as trainers 
here on
the lists. Users of special algorithms are supposed to be experts 
themselves

and should understand what they are doing. Or do you expect that any
arbitrary user can use genetic algorithms or neuronal network stuff 
without

the mathematical background?


No, I do not expect that.
[Although it is sometimes part of the resolution of a bug report, and
something that gives a sense of "you are welcome here".]

The main point is about real bugs that won't be handled (see below).


Anything is well and can be released as long as the existing code is
verified by unit tests. Otherwise we would have to remove a lot of 
code
every time we release a component ... or do you expect e.g. that the 
release

manager of vfs understands completely any of its providers?


No, certainly not, since I could RM CM. ;-)

But that's not the point!

_Some_ developer(s) should be able to support whatever is in 
development.

Otherwise how can it be deemed "in development"?

Just today, two issues were reported on JIRA:
  https://issues.apache.org/jira/browse/MATH-172
  https://issues.apache.org/jira/browse/MATH-1375

They, unfortunately, illustrate my point.

Moreover what could be true for VFS is not for CM where there are many,
many different areas that have nothing in common (except perhaps some
ubiquitous very-low utilities which might be worth their own component
to serve as a, maybe "internal", dependency).

Also, compare the source basic statistics (lines of code):
  VFS  CM
Java code24215   90834
Unit tests8926   95595

All in all, CM is more than 5 times larger than VFS (not even counting
documentation).


​I think that clustering part could be generalized to ML package
as a

whole.​



Fine I guess, since currently the "neuralnet" sub-package's only
concrete functionality is also a clustering method.



​I was also wondering whenever ML package meant to be extended in
the future


Really there was no plan, or as many plans as there were 
developers...


Putting all these codes (with different designs, different coding
practices, different intended audiences, 

Build failed in Jenkins: Commons-Compress #113

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-us1 (Ubuntu ubuntu ubuntu-us golang-ppa) in 
workspace 
java.io.IOException: Failed to install 
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.0.4/apache-maven-3.0.4-bin.zip
 to /home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:75)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at 
hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:108)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:624)
at 
hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:183)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1046)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: java.io.IOException: remote file operation failed: 
/home/jenkins/tools/maven/apache-maven-3.0.4 at 
hudson.remoting.Channel@5d1f9326:ubuntu-us1: 
java.nio.file.AccessDeniedException: 
/home/jenkins/tools/maven/apache-maven-3.0.4/.installedFrom
at hudson.FilePath.act(FilePath.java:986)
at hudson.FilePath.act(FilePath.java:968)
at hudson.FilePath.deleteContents(FilePath.java:1183)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:796)
... 16 more
Caused by: java.nio.file.AccessDeniedException: 
/home/jenkins/tools/maven/apache-maven-3.0.4/.installedFrom
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
at 
sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1077)
at sun.reflect.GeneratedMethodAccessor1517.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at hudson.Util.deleteFile(Util.java:255)
at hudson.FilePath.deleteRecursive(FilePath.java:1203)
at hudson.FilePath.deleteContentsRecursive(FilePath.java:1212)
at hudson.FilePath.access$1100(FilePath.java:190)
at hudson.FilePath$15.invoke(FilePath.java:1186)
at hudson.FilePath$15.invoke(FilePath.java:1183)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2719)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to ubuntu-us1(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at hudson.FilePath.act(FilePath.java:979)
... 19 more
Retrying after 10 seconds
java.io.IOException: Failed to install 
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.0.4/apache-maven-3.0.4-bin.zip
 to /home/jenkins/tools/maven/apache-maven-3.0.4
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832)
at 
hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:75)
at 
hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
  

[compress] Preparing for 1.12

[Stefan Bodewig]

Hi all

we've got a nice set of fixes and new features added since 1.11 and I
plan to cut the next release soonish. The only thing I want to do prior
to the release is adding a few words of documentation about the IWA
support in Snappy.

Based on prior experience I'd like to give folks a chance to look at the
current site build at
, in
particular at the reports.

You'll see that findbugs is unhappy about inconsistent synchronization
introduced when I made the finish method of BZip2CompressorOutputStream
synchronized due to COMPRESS-357

Yes, blockSorter is accessed unsynchronized in different places, but we
don't need to care as the class isn't thread safe anyway and all we
wanted to do is to avoid a race condition with GC. I'd prefer to
suppress the warning over synchronizing more of the class.

Any feedback more than welcome.

Stefan

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

Re: [crypto] Logging dependency

[Gary Gregory]

On Thu, Jun 9, 2016 at 11:19 AM, Matt Sicker  wrote:

> There is a huge list of advantages to using log4j-api over slf4j-api
> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> unless the competition is clearly better for the use case (like using Jetty
> instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
> works fine with logback as well, so it's not like it prevents people from
> using slf4j bindings at runtime.
>

+1 to log4j-api or no logging. (JUL is possible but has all of its known
problems.)

Gary


>
> On 8 June 2016 at 05:51, James Carman  wrote:
>
> > On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory 
> > wrote:
> >
> > > Hi All:
> > >
> > > IMO. if [crypto] is to have a dependency on a logging framework, it
> > should
> > > be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you
> can
> > > pair with any number of implementations: Log4j's own Core, JUL, SLF4J,
> > and
> > > so on.
> > >
> > >
> > I would prefer SLF4J, personally.  It is by far the most popular based on
> > my experience with the libraries that I use.  This is assuming the
> > component does use a logging framework.  Others have suggested that it
> does
> > not.  I don't know that it really matters to me one way or the other,
> but I
> > do know that in the past when I didn't have any logging when things went
> > bump, it was hard to determine what to do to fix it.  Some folks keep JMX
> > stats and the like to help and I suppose that's an option.
> >
>
>
>
> --
> Matt Sicker 
>



-- 
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: [crypto] Logging dependency

[Matt Sicker]

There is a huge list of advantages to using log4j-api over slf4j-api
nowadays, plus I do prefer to use Apache dependencies in Apache projects
unless the competition is clearly better for the use case (like using Jetty
instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
works fine with logback as well, so it's not like it prevents people from
using slf4j bindings at runtime.

On 8 June 2016 at 05:51, James Carman  wrote:

> On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory 
> wrote:
>
> > Hi All:
> >
> > IMO. if [crypto] is to have a dependency on a logging framework, it
> should
> > be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can
> > pair with any number of implementations: Log4j's own Core, JUL, SLF4J,
> and
> > so on.
> >
> >
> I would prefer SLF4J, personally.  It is by far the most popular based on
> my experience with the libraries that I use.  This is assuming the
> component does use a logging framework.  Others have suggested that it does
> not.  I don't know that it really matters to me one way or the other, but I
> do know that in the past when I didn't have any logging when things went
> bump, it was hard to determine what to do to fix it.  Some folks keep JMX
> stats and the like to help and I suppose that's an option.
>



-- 
Matt Sicker 

Re: [Math] Commons Math (r)evolution

[Artem Barger]

 On Thu, Jun 9, 2016 at 1:54 AM, Gilles 
wrote:

> ​I guess someone need to prioritize them​ according to they importance for
>
>> release.
>>
>
> Importance is relative... :-}
>

​Indeed it's very objective function,  however someone has to decide
where to focus.​



> IMO, it is important to not release unsupported code.
> So the priority would be higher for issues that would be included
> in the release of the new Commons components.
> Hence the need to figure out what these components will be.
>

​Not clear whenever you really mean by not releasing unsupported code is
to exclude already existing parts which doesn't anyone who will be capable
to maintain the functionality and solve possible bugs?​



>
>>> Which ones?
>>>
>>> ​I will look into JIRA and provide the issue numbers, and of course I
>> can cover and assist with ML part and particular clustering.​
>>
>
> Thanks.
>

​You are welcome :)
So I looked through some of the open issues and I have a couple of
questions them​:

1. Which affected version do I really need to consider as an important to
be
released in the next version?
2. I've looked into affected versions: 3.5, 3.6, 3.6.1, 3.7 and 4.0.
Overall found
something like ~25 open bugs/issues. What about issues opened for lower
releases?

For example while I'm looking into MATH-1329
, it sounds not really
hard to have it fixed,
but looking on it not sure whenever it was accepted and approved as
something that need
to be done.

Next MATH-1315  seems like
reported has provided the patch and the only thing
missing is unit test, will addition of unit tests help to make that one
resolved?

MATH-1284  here is not
clear what is the final decision, according to comments look
like it can be resolved.

Here MATH-1262  according
to the comments editing current javadoc to explain the limitation
should also rest this case, am I missing something?

I think I can help to handle MATH-1281
, right after I will
finish the refactoring and
optimizations for kmeans clustering.

​Listed issues/tickets where I can help to provide support or fix, most
likely missed something
but can start with these.​


> with additional functionality, since I think I can provide my code for
>> several classification
>> algorithms​.
>>
>
> That sounds nice.
> Which algorithms?
>
>
​Naive Bayes, kNN, Decision Trees, Random Forest. I guess adding these into
the project will require
serious redesign of ML package​.

Re: [VFS] CI in POM?

[Gary Gregory]

On Thu, Jun 9, 2016 at 12:24 AM,  wrote:

> Hello,
>
> I will take a look at the failing solaris builds, something in the hadoop
> test cluster does not work there.
>
> Jenkins Karma would be fine, Gary. (e...@apache.org)
>

Done.

Gary


>
> Can I sent failed jobs announcement to dev@ or maybe the commit@ list, i
> think we had that for continuum before.
>
> I will check how to get the jenkins-url in the POM, maybe I need to update
> the parent version (it is not currently in the effective pom of vfs)
>
> Gruss
> Bernd
>
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Do., 09 Juni 2016 9:20
> Subject: Re: [VFS] CI in POM?
>
> Bernd, if you like, Gary can grant you karma for Jenkins.
>
> AFAIK Jenkins has already been added to parent POM.
>
> Benedikt
>
> Gary Gregory  schrieb am Do., 9. Juni 2016 um
> 01:03:
>
> > On Wed, Jun 8, 2016 at 3:59 PM,  wrote:
> >
> > > Thanks, had found it meanwhile. Should we add Jenkins to the parent POM
> > or
> > > a more specific section into the project pom?
> > >
> > > Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java
> > 7,
> > > the Jobs fail since that change:
> > >
> > >  > > (latest),label=Ubuntu/431/>
> > >
> >
> > Done and building...
> >
> > Gary
> >
> > >
> > > Gruss
> > > Bernd
> > >
> > > --
> > > http://bernd.eckenfels.net
> > >
> > > -Original Message-
> > > From: Gary Gregory 
> > > To: Commons Developers List 
> > > Sent: Do., 09 Juni 2016 0:50
> > > Subject: Re: [VFS] CI in POM?
> > >
> > > Continuum has been retired:
> > > https://attic.apache.org/projects/continuum.html
> > >
> > > We need use switch Jenkins:
> > > https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/
> > >
> > > Gary
> > >
> > > On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels <
> e...@zusammenkunft.net>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > continuum-ci.apache.org seems to be gone, or at least it is not
> > > > responding right now. In the VFS POM we have a CI section (from the
> > > > parent) poiting to this CI.
> > > >
> > > > Should this be replaced by some other integration server, if yes,
> where
> > > > is the Job currently setup?
> > > >
> > > > (And I havent found the info on the commons.apache.org site easily,
> > > > should we do something about that?)
> > > >
> > > > I think there is somewhere a Jenkins running (for us?)
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> >
> > --
> > 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
>
>


-- 
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] Commons Math (r)evolution

[Jörg Schaible]

Hi Gilles,

Gilles wrote:

> Hi.
> 
> On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:
>> On Wed, Jun 8, 2016 at 12:25 AM, Gilles
>> 
>> wrote:
>>
>>>
>>> According to JIRA, among 180 issues currently targeted for the
> next major release (v4.0), 139 have been resolved (75 of which
> were not in v3.6.1).
>
>
 ​Huh, it's above of 75% completion :)​

>>>
>>> Everybody is welcome to review the "open" issues and comment
>>> about them.
>>>
>>>
>> ​I guess someone need to prioritize them​ according to they
>> importance for
>> release.
> 
> Importance is relative... :-}
> 
> IMO, it is important to not release unsupported code.

Unit test *are* kind of support.

> So the priority would be higher for issues that would be included
> in the release of the new Commons components.
> Hence the need to figure out what these components will be.
> 
> Of course, anyone who wishes to maintain some of these codes
>
> (answer user questions, fix bugs, create enhancements, etc.)
> is most welcome to step forward.
>
>
 ​I can try to cover some of these and maintain relevant code
 parts.​

>>>
>>> Which ones?
>>>
>> ​I will look into JIRA and provide the issue numbers, and of course I
>> can cover and assist with ML part and particular clustering.​
> 
> Thanks.
> 
>>>
>>> IMO, a maintainer is someone who is able to respond to user
>>> questions and to figure out whether a bug report is valid.
>>>
>>
>> ​I'm subscribed for mailing list for quite a while and haven't
>> seen a lot of questions coming from user​s.
> 
> The "user" ML has always been fairly quiet.
> Does it mean that the code is really easy to use?
> Or feature-complete (I doubt that)?
> Or that there are very few users for the most complex features?
> 
> The "dev" ML was usually (much) more active.
> 
> The point is that when someone asks a question or propose an
> contribution, there must be someone to answer.

And this is IMHO a wrong assumption. We have a lot of components where the 
original authors have left long ago. So the situation is not new.

Math is a specialized library and nobody expects that it is accompanied by 
tutorials explaining the theory or developers that act as trainers here on 
the lists. Users of special algorithms are supposed to be experts themselves 
and should understand what they are doing. Or do you expect that any 
arbitrary user can use genetic algorithms or neuronal network stuff without 
the mathematical background?

Anything is well and can be released as long as the existing code is 
verified by unit tests. Otherwise we would have to remove a lot of code 
every time we release a component ... or do you expect e.g. that the release 
manager of vfs understands completely any of its providers?

> ​I think that clustering part could be generalized to ML package
> as a
 whole.​

>>>
>>> Fine I guess, since currently the "neuralnet" sub-package's only
>>> concrete functionality is also a clustering method.
>>>
>>>
>> ​I was also wondering whenever ML package meant to be extended in
>> the future
> 
> Really there was no plan, or as many plans as there were developers...
> 
> Putting all these codes (with different designs, different coding
> practices, different intended audiences, different levels of expertise,
> etc.) in a single library was not sustainable.
> 
> That's why I strongly favour cutting this monolith into pieces
> with a limited scope.

Nobody objects, but if you look at vfs, it is still *one* Apache Commons 
component, just with multiple artifacts. All these artifacts are released 
*together*. Turning math into a multi-project has nothing to do with your 
plans to drop mature code, because you (and currently no-one else) cannot 
answer questions to its functionality.

Cheers,
Jörg


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

[GitHub] commons-bcel pull request #6: Fix for BCEL-273

[iloveeclipse]

GitHub user iloveeclipse opened a pull request:

https://github.com/apache/commons-bcel/pull/6

Fix for BCEL-273

Fixes BCEL-273 by partly reverting adf9fc13b37f866d731c73a09071170d50bfa807.

This allows FindBugs to run on latest greatest BCEL state and avoid 
exceptions below:

java.lang.ClassCastException: edu.umd.cs.findbugs.bcel.generic.NULL2Z
cannot be cast to org.apache.commons.bcel6.generic.BranchInstruction
At
org.apache.commons.bcel6.generic.BranchHandle.getBI(BranchHandle.java:64)
At

org.apache.commons.bcel6.generic.BranchHandle.getPosition(BranchHandle.java:73)
At

edu.umd.cs.findbugs.ba.BetterCFGBuilder2$Subroutine.addInstruction(BetterCFGBuilder2.java:296)
At
edu.umd.cs.findbugs.ba.BetterCFGBuilder2.build(BetterCFGBuilder2.java:867)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/iloveeclipse/commons-bcel BCEL-273

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-bcel/pull/6.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #6


commit 25dfa20fd99e4053e68b6054ff21f55fd915e003
Author: Andrey Loskutov 
Date:   2016-06-08T13:27:07Z

Fixes BCEL-273 by partly reverting
adf9fc13b37f866d731c73a09071170d50bfa807.

java.lang.ClassCastException: edu.umd.cs.findbugs.bcel.generic.NULL2Z
cannot be cast to org.apache.commons.bcel6.generic.BranchInstruction
At
org.apache.commons.bcel6.generic.BranchHandle.getBI(BranchHandle.java:64)
At

org.apache.commons.bcel6.generic.BranchHandle.getPosition(BranchHandle.java:73)
At

edu.umd.cs.findbugs.ba.BetterCFGBuilder2$Subroutine.addInstruction(BetterCFGBuilder2.java:296)
At
edu.umd.cs.findbugs.ba.BetterCFGBuilder2.build(BetterCFGBuilder2.java:867)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [VFS] CI in POM?

[Benedikt Ritter]

 schrieb am Do., 9. Juni 2016 um 09:24 Uhr:

> Hello,
>
> I will take a look at the failing solaris builds, something in the hadoop
> test cluster does not work there.
>
> Jenkins Karma would be fine, Gary. (e...@apache.org)
>
> Can I sent failed jobs announcement to dev@ or maybe the commit@ list, i
> think we had that for continuum before.
>

Some of the jobs notify dev@
We also have notifications@ but I can not remember what we created it for
:o)


>
> I will check how to get the jenkins-url in the POM, maybe I need to update
> the parent version (it is not currently in the effective pom of vfs)
>
> Gruss
> Bernd
>
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Do., 09 Juni 2016 9:20
> Subject: Re: [VFS] CI in POM?
>
> Bernd, if you like, Gary can grant you karma for Jenkins.
>
> AFAIK Jenkins has already been added to parent POM.
>
> Benedikt
>
> Gary Gregory  schrieb am Do., 9. Juni 2016 um
> 01:03:
>
> > On Wed, Jun 8, 2016 at 3:59 PM,  wrote:
> >
> > > Thanks, had found it meanwhile. Should we add Jenkins to the parent POM
> > or
> > > a more specific section into the project pom?
> > >
> > > Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java
> > 7,
> > > the Jobs fail since that change:
> > >
> > >  > > (latest),label=Ubuntu/431/>
> > >
> >
> > Done and building...
> >
> > Gary
> >
> > >
> > > Gruss
> > > Bernd
> > >
> > > --
> > > http://bernd.eckenfels.net
> > >
> > > -Original Message-
> > > From: Gary Gregory 
> > > To: Commons Developers List 
> > > Sent: Do., 09 Juni 2016 0:50
> > > Subject: Re: [VFS] CI in POM?
> > >
> > > Continuum has been retired:
> > > https://attic.apache.org/projects/continuum.html
> > >
> > > We need use switch Jenkins:
> > > https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/
> > >
> > > Gary
> > >
> > > On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels <
> e...@zusammenkunft.net>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > continuum-ci.apache.org seems to be gone, or at least it is not
> > > > responding right now. In the VFS POM we have a CI section (from the
> > > > parent) poiting to this CI.
> > > >
> > > > Should this be replaced by some other integration server, if yes,
> where
> > > > is the Job currently setup?
> > > >
> > > > (And I havent found the info on the commons.apache.org site easily,
> > > > should we do something about that?)
> > > >
> > > > I think there is somewhere a Jenkins running (for us?)
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> >
> > --
> > 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: [VFS] CI in POM?

[ecki]

Hello,

I will take a look at the failing solaris builds, something in the hadoop test 
cluster does not work there.

Jenkins Karma would be fine, Gary. (e...@apache.org)

Can I sent failed jobs announcement to dev@ or maybe the commit@ list, i think 
we had that for continuum before.

I will check how to get the jenkins-url in the POM, maybe I need to update the 
parent version (it is not currently in the effective pom of vfs)

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Benedikt Ritter 
To: Commons Developers List 
Sent: Do., 09 Juni 2016 9:20
Subject: Re: [VFS] CI in POM?

Bernd, if you like, Gary can grant you karma for Jenkins.

AFAIK Jenkins has already been added to parent POM.

Benedikt

Gary Gregory  schrieb am Do., 9. Juni 2016 um 01:03:

> On Wed, Jun 8, 2016 at 3:59 PM,  wrote:
>
> > Thanks, had found it meanwhile. Should we add Jenkins to the parent POM
> or
> > a more specific section into the project pom?
> >
> > Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java
> 7,
> > the Jobs fail since that change:
> >
> >  > (latest),label=Ubuntu/431/>
> >
>
> Done and building...
>
> Gary
>
> >
> > Gruss
> > Bernd
> >
> > --
> > http://bernd.eckenfels.net
> >
> > -Original Message-
> > From: Gary Gregory 
> > To: Commons Developers List 
> > Sent: Do., 09 Juni 2016 0:50
> > Subject: Re: [VFS] CI in POM?
> >
> > Continuum has been retired:
> > https://attic.apache.org/projects/continuum.html
> >
> > We need use switch Jenkins:
> > https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/
> >
> > Gary
> >
> > On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels 
> > wrote:
> >
> > > Hello,
> > >
> > > continuum-ci.apache.org seems to be gone, or at least it is not
> > > responding right now. In the VFS POM we have a CI section (from the
> > > parent) poiting to this CI.
> > >
> > > Should this be replaced by some other integration server, if yes, where
> > > is the Job currently setup?
> > >
> > > (And I havent found the info on the commons.apache.org site easily,
> > > should we do something about that?)
> > >
> > > I think there is somewhere a Jenkins running (for us?)
> > >
> > > Gruss
> > > Bernd
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > 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
> >
> >
>
>
> --
> 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: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

[Benedikt Ritter]

Why? This was a good idea.

 schrieb am Do., 9. Juni 2016 um 02:48:

> Author: niallp
> Date: Thu Jun  9 00:48:17 2016
> New Revision: 1747476
>
> URL: http://svn.apache.org/viewvc?rev=1747476=rev
> Log:
> Revert Crypto changes
>
> Modified:
> commons/cms-site/trunk/content/site.xml
> commons/cms-site/trunk/content/xdoc/components.xml
> commons/cms-site/trunk/content/xdoc/index.xml.vm
>
> Modified: commons/cms-site/trunk/content/site.xml
> URL:
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/site.xml?rev=1747476=1747475=1747476=diff
>
> ==
> --- commons/cms-site/trunk/content/site.xml (original)
> +++ commons/cms-site/trunk/content/site.xml Thu Jun  9 00:48:17 2016
> @@ -54,7 +54,6 @@
>  
>  
>  
> -
>  
>  
>  
>
> Modified: commons/cms-site/trunk/content/xdoc/components.xml
> URL:
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/components.xml?rev=1747476=1747475=1747476=diff
>
> ==
> --- commons/cms-site/trunk/content/xdoc/components.xml (original)
> +++ commons/cms-site/trunk/content/xdoc/components.xml Thu Jun  9 00:48:17
> 2016
> @@ -55,8 +55,6 @@
>  Defines an API for working with tar, zip and bzip2
> files.
>  Configuration
>  Reading of configuration/preferences files in various
> formats.
> -Crypto
> -A cryptographic library optimized with AES-NI wrapping
> Openssl or JCE algorithm implementations
>  CSV
>  Component for reading and writing comma separated value
> files.
>  Daemon
>
> Modified: commons/cms-site/trunk/content/xdoc/index.xml.vm
> URL:
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/index.xml.vm?rev=1747476=1747475=1747476=diff
>
> ==
> --- commons/cms-site/trunk/content/xdoc/index.xml.vm (original)
> +++ commons/cms-site/trunk/content/xdoc/index.xml.vm Thu Jun  9 00:48:17
> 2016
> @@ -119,9 +119,6 @@
>   href="proper/commons-configuration/">Configuration
>  Reading of configuration/preferences files in various
> formats.
>
>  ${configurationVersion}${configurationReleased}
> -Crypto
> -A cryptographic library optimized with AES-NI wrapping
> Openssl or JCE algorithm implementations.
> -${cryptoVersion}${cryptoReleased}
>  CSV
>  Component for reading and writing comma separated value
> files.
>  ${csvVersion}${csvReleased}
>
>
>

Re: [VFS] CI in POM?

[Benedikt Ritter]

Bernd, if you like, Gary can grant you karma for Jenkins.

AFAIK Jenkins has already been added to parent POM.

Benedikt

Gary Gregory  schrieb am Do., 9. Juni 2016 um 01:03:

> On Wed, Jun 8, 2016 at 3:59 PM,  wrote:
>
> > Thanks, had found it meanwhile. Should we add Jenkins to the parent POM
> or
> > a more specific section into the project pom?
> >
> > Can anybody with Jenkins Karma reconfigure the Jobs to use minimum Java
> 7,
> > the Jobs fail since that change:
> >
> >  > (latest),label=Ubuntu/431/>
> >
>
> Done and building...
>
> Gary
>
> >
> > Gruss
> > Bernd
> >
> > --
> > http://bernd.eckenfels.net
> >
> > -Original Message-
> > From: Gary Gregory 
> > To: Commons Developers List 
> > Sent: Do., 09 Juni 2016 0:50
> > Subject: Re: [VFS] CI in POM?
> >
> > Continuum has been retired:
> > https://attic.apache.org/projects/continuum.html
> >
> > We need use switch Jenkins:
> > https://builds.apache.org/view/Apache%20Commons/job/commons-vfs-trunk/
> >
> > Gary
> >
> > On Wed, Jun 8, 2016 at 3:35 PM, Bernd Eckenfels 
> > wrote:
> >
> > > Hello,
> > >
> > > continuum-ci.apache.org seems to be gone, or at least it is not
> > > responding right now. In the VFS POM we have a CI section (from the
> > > parent) poiting to this CI.
> > >
> > > Should this be replaced by some other integration server, if yes, where
> > > is the Job currently setup?
> > >
> > > (And I havent found the info on the commons.apache.org site easily,
> > > should we do something about that?)
> > >
> > > I think there is somewhere a Jenkins running (for us?)
> > >
> > > Gruss
> > > Bernd
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> > --
> > 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
> >
> >
>
>
> --
> 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
>

[crypto]

[Gary Gregory]

When I build on Linux, I get some warnings. Can we get these fixed?

make:
 [exec] compiling OSInfo.java
 [exec] make: Warning: File
'target/classes/org/apache/commons/crypto/VERSION' has modification time
6.1 s in the future
 [exec] "$JAVA_HOME/bin/javac" -source 1.6 -target 1.6 -d
target/jni-classes -sourcepath src/main/java
src/main/java/org/apache/commons/crypto/random/OpensslCryptoRandomNative.java
 [exec] warning: [options] bootstrap class path not set in conjunction
with -source 1.6
 [exec] 1 warning
 [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o
target/jni-classes/org/apache/commons/crypto/random/OpensslCryptoRandomNative.h
org.apache.commons.crypto.random.OpensslCryptoRandomNative
 [exec] gcc -I/usr/lib/jvm/java-8-openjdk-i386/include -O2 -fPIC
-fvisibility=hidden -m32 -Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/usr/lib/jvm/java-8-openjdk-i386/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.0.0-SNAPSHOT-Linux-x86/OpensslCryptoRandom.o
 [exec]
src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c:37:0:
warning: "JNIEXPORT" redefined
 [exec]  #define JNIEXPORT __attribute__((__visibility__("default")))
 [exec]  ^
 [exec] In file included from
/usr/lib/jvm/java-8-openjdk-i386/include/jni.h:45:0,
 [exec]  from
src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:71,
 [exec]  from
src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22,
 [exec]  from
src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c:19:
 [exec] /usr/lib/jvm/java-8-openjdk-i386/include/linux/jni_md.h:33:0:
note: this is the location of the previous definition
 [exec]#define JNIEXPORT __attribute__((visibility("default")))
 [exec]  ^
 [exec] "$JAVA_HOME/bin/javac" -source 1.6 -target 1.6 -d
target/jni-classes -sourcepath src/main/java
src/main/java/org/apache/commons/crypto/cipher/OpensslNative.java
 [exec] warning: [options] bootstrap class path not set in conjunction
with -source 1.6
 [exec] 1 warning
 [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o
target/jni-classes/org/apache/commons/crypto/cipher/OpensslNative.h
org.apache.commons.crypto.cipher.OpensslNative
 [exec] gcc -I/usr/lib/jvm/java-8-openjdk-i386/include -O2 -fPIC
-fvisibility=hidden -m32 -Ilib/include -I/usr/include
-I"src/main/native/org/apache/commons/crypto/"
-I"/usr/lib/jvm/java-8-openjdk-i386/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/cipher/OpensslNative.c -o
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/OpensslNative.o
 [exec]
src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c:26:0:
warning: "JNIEXPORT" redefined
 [exec]  #define JNIEXPORT __attribute__((__visibility__("default")))
 [exec]  ^
 [exec] In file included from
/usr/lib/jvm/java-8-openjdk-i386/include/jni.h:45:0,
 [exec]  from
src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:71,
 [exec]  from
src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c:19:
 [exec] /usr/lib/jvm/java-8-openjdk-i386/include/linux/jni_md.h:33:0:
note: this is the location of the previous definition
 [exec]#define JNIEXPORT __attribute__((visibility("default")))
 [exec]  ^
 [exec] g++ -I/usr/lib/jvm/java-8-openjdk-i386/include -O2 -fPIC
-fvisibility=hidden -m32 -Ilib/include  -I/usr/include
-I"/usr/lib/jvm/java-8-openjdk-i386/include/linux"
-I"target/jni-classes/org/apache/commons/crypto/cipher"
-I"target/jni-classes/org/apache/commons/crypto/random" -o
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/libcommons-crypto.so
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/OpensslCryptoRandom.o
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/OpensslNative.o -shared
-static-libgcc -static-libstdc++
 [exec] strip
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/libcommons-crypto.so
 [exec] cp
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/libcommons-crypto.so
target/classes/org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so
 [exec] cp
target/commons-crypto-1.0.0-SNAPSHOT-Linux-x86/libcommons-crypto.so
target/classes/org/apache/commons/crypto/native/Linux/x86/libcommons-crypto.so
 [exec] make: warning:  Clock skew detected.  Your build may be
incomplete.

Thank you,
Gary

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

JUnit in Action, Second Edition 

Jenkins build is back to normal : Commons-configuration #7

[Apache Jenkins Server]

See 


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