Hi folks!
I've moved the TCK run into an own profile. You can activate it via
$ mvn clean install -PjcacheTck
We should also activate it by default during a release.
Btw, why is this project target 1.7? We do not use anything from java7 right?
LieGrue,
strub
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=29989projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 08:00:03 +
Finished at: Thu 1 May 2014 08:04:16 +
Total time: 4m 12s
Build Trigger:
tck does
would be great to get it activated by default when java 6 too
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-01 9:52 GMT+02:00 Mark Struberg
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=29992projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 08:20:40 +
Finished at: Thu 1 May 2014 08:24:15 +
Total time: 3m 35s
Build Trigger:
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=29993projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 09:00:03 +
Finished at: Thu 1 May 2014 09:04:20 +
Total time: 4m 16s
Build Trigger:
I would prefer it if the reports were warnings rather than errors, but
generally they seem sensible.
Allow me to disagree. Breaking the javadoc just because a @param is missing is
imo plain wrong.
Usually parameters should be self-explaining. I personally only document
interfaces and methods
Actually the ',' causes a bug in the maven-javadoc-plugin. What seems to work
is to split it into 2 parts:
additionalparam-Xdoclint:all -Xdoclint:-missing/additionalparam
Already started a discussion about adding it to apache-parent over in maven-dev.
LieGrue,
strub
On Thursday, 1 May
Well, the TCK runs fine with source and target 1.6. There is nothing in our
code which requires java7 yet. Thus there is imo no reason to force it.
LieGrue,
strub
On Thursday, 1 May 2014, 9:53, Mark Struberg strub...@yahoo.de wrote:
Hi folks!
I've moved the TCK run into an own
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=29998projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 11:00:03 +
Finished at: Thu 1 May 2014 11:04:07 +
Total time: 4m 4s
Build Trigger:
wait think we didnt get each other - we say the same thing I think -,
core and jcache module are built to target j6. Only tck module should
run on j7/8. There are no other restriction and j6 is clearly targeted
by jcache module.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog:
Yes but source and target have been set to 1.7 in the parent pom.
Changed this back to 1.6 now.
LieGrue,
strub
On Thursday, 1 May 2014, 13:03, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
wait think we didnt get each other - we say the same thing I think -,
core and jcache module
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30002projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 11:24:06 +
Finished at: Thu 1 May 2014 11:28:10 +
Total time: 4m 4s
Build Trigger:
oh right, changed it in my JCS.patch ;). Sorry forgit it
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-01 13:16 GMT+02:00 Mark Struberg strub...@yahoo.de:
Yes but
On Thu, 01 May 2014 12:14:14 -, t...@apache.org wrote:
Author: tn
Date: Thu May 1 12:14:14 2014
New Revision: 1591631
URL: http://svn.apache.org/r1591631
Log:
Disable randomly failing unit test.
Modified:
On 05/01/2014 02:55 PM, Gilles wrote:
On Thu, 01 May 2014 12:14:14 -, t...@apache.org wrote:
Author: tn
Date: Thu May 1 12:14:14 2014
New Revision: 1591631
URL: http://svn.apache.org/r1591631
Log:
Disable randomly failing unit test.
Modified:
On 1 May 2014 12:05, t...@apache.org wrote:
Author: tn
Date: Thu May 1 11:04:59 2014
New Revision: 1591602
URL: http://svn.apache.org/r1591602
Log:
[COLLECTIONS-519] Constructors of *Utils classes are now protected to allow
sub-classing. Thanks to Radoslav Paskalev, Daniel Feist.
-1
I
Le 01/05/2014 14:55, Gilles a écrit :
Please provide a stack trace.
Here it is (with Java 8 on Windows and OpenJDK 8 on Debian) :
---
Test set: org.apache.commons.math3.ml.neuralnet.NetworkTest
On 05/01/2014 03:03 PM, sebb wrote:
On 1 May 2014 12:05, t...@apache.org wrote:
Author: tn
Date: Thu May 1 11:04:59 2014
New Revision: 1591602
URL: http://svn.apache.org/r1591602
Log:
[COLLECTIONS-519] Constructors of *Utils classes are now protected to allow
sub-classing. Thanks to
On Thu, May 1, 2014 at 9:03 AM, sebb seb...@gmail.com wrote:
On 1 May 2014 12:05, t...@apache.org wrote:
Author: tn
Date: Thu May 1 11:04:59 2014
New Revision: 1591602
URL: http://svn.apache.org/r1591602
Log:
[COLLECTIONS-519] Constructors of *Utils classes are now protected to
On Thu, 01 May 2014 15:13:53 +0200, Emmanuel Bourg wrote:
Le 01/05/2014 14:55, Gilles a écrit :
Please provide a stack trace.
Here it is (with Java 8 on Windows and OpenJDK 8 on Debian) :
---
Test set:
On 01.05.14 09:52, Mark Struberg wrote:
Hi folks!
I've moved the TCK run into an own profile. You can activate it via
$ mvn clean install -PjcacheTck
We should also activate it by default during a release.
Btw, why is this project target 1.7? We do not use anything from java7 right?
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30011projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 1 May 2014 14:20:51 +
Finished at: Thu 1 May 2014 14:26:10 +
Total time: 5m 18s
Build Trigger: Schedule
On 1 May 2014 15:13, Thomas Neidhart thomas.neidh...@gmail.com wrote:
On 05/01/2014 03:39 PM, sebb wrote:
On 1 May 2014 14:21, Thomas Neidhart thomas.neidh...@gmail.com wrote:
On 05/01/2014 03:03 PM, sebb wrote:
On 1 May 2014 12:05, t...@apache.org wrote:
Author: tn
Date: Thu May 1
sebb wrote:
On 1 May 2014 14:21, Thomas Neidhart thomas.neidh...@gmail.com wrote:
On 05/01/2014 03:03 PM, sebb wrote:
On 1 May 2014 12:05, t...@apache.org wrote:
Author: tn
Date: Thu May 1 11:04:59 2014
New Revision: 1591602
URL: http://svn.apache.org/r1591602
Log:
[COLLECTIONS-519]
Wrong syntax is different than missing syntax. The former affects
readability while the other just affects usability. Glad you found a way to
catch the former but ignore the latter.
On Thu, May 1, 2014 at 5:22 AM, Mark Struberg strub...@yahoo.de wrote:
Actually the ',' causes a bug in the
Hi all,
I would like to call a vote to release Commons Math 3.3 based on RC2.
Changes since RC1:
* completed changelog
* fixed MATH-1110
* added exclusion filter for findbugs false-positive
* disabled 2 tests that failed with Java 8
* javadoc fixes for Java 8 (incomplete, see below)
Note:
Am Thu, 1 May 2014 11:01:32 -0500
schrieb Paul Benedict pbened...@apache.org:
Wrong syntax is different than missing syntax. The former affects
readability while the other just affects usability. Glad you found a
way to catch the former but ignore the latter.
I agree with the missing should
Hi!
I've looked at Continuum and it seems like it fails since weeks now.
Anyone successfully did run it with jdk-1.6?
If so, we should rather look at the Continuum config.
LieGrue,
strub
On Thursday, 1 May 2014, 16:39, Thomas Vandahl t...@apache.org wrote:
On 01.05.14 09:52, Mark
Le 01/05/2014 15:28, Gilles a écrit :
On Thu, 01 May 2014 15:13:53 +0200, Emmanuel Bourg wrote:
Thanks; could you please run it with the latest trunk (line numbers are
wrong)?
On the trunk it fails at line 131:
Assert.assertTrue(isUnspecifiedOrder);
(Adding error messages to the
-1
Imho this usecase also gives a false impression of over riding, so maybe we
should make the util classes final as Gary suggested. And imo switching to
Guava would be much more of an effort than to compose ones own util class :)
On Thursday, 1 May 2014, Jörg Schaible
Hello,
in preparation of the VFS2.1 release I was reviewing the Clirr report.
It has quite a number of errors, especially in regard to new Interface
methods.
# Method 'public long write(org.apache.commons.vfs2.FileContent)' has
been added to an interface
# Method 'public boolean isFile()' has
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30022projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 20:00:03 +
Finished at: Thu 1 May 2014 20:04:29 +
Total time: 4m 25s
Build Trigger:
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=30025projectId=286
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 1 May 2014 20:20:47 +
Finished at: Thu 1 May 2014 20:24:31 +
Total time: 3m 43s
Build Trigger:
Hi.
I don't like most of the changes performed on the Javadoc; most of them
are going in the wrong direction IMHO, the most severe being the use of
HTML entities rather than using MathJax.[1]
Last time I checked W3C was trying to make HTML a valid XML language;
now from what I read in this
On Thu, 01 May 2014 18:25:46 +0200, Emmanuel Bourg wrote:
Le 01/05/2014 15:28, Gilles a écrit :
On Thu, 01 May 2014 15:13:53 +0200, Emmanuel Bourg wrote:
Thanks; could you please run it with the latest trunk (line numbers
are
wrong)?
On the trunk it fails at line 131:
Thanks.
On 05/01/2014 10:31 PM, Gilles wrote:
Hi.
I don't like most of the changes performed on the Javadoc; most of them
are going in the wrong direction IMHO, the most severe being the use of
HTML entities rather than using MathJax.[1]
well, this does not really come as a surprise.
But
GitHub user maximenay opened a pull request:
https://github.com/apache/commons-collections/pull/1
COLLECTIONS-521 Typo in MultiMapKey's isEqualKey(entry, key1, key2)
https://issues.apache.org/jira/browse/COLLECTIONS-521
You can merge this pull request into a Git repository by
On Thu, 01 May 2014 18:15:39 +0200, Thomas Neidhart wrote:
Hi all,
I would like to call a vote to release Commons Math 3.3 based on RC2.
Changes since RC1:
* completed changelog
* fixed MATH-1110
* added exclusion filter for findbugs false-positive
* disabled 2 tests that failed with Java
Personally, I don't see a reason to revert the javadoc changes. There's no
turning back the clock on the javadoc processing engine -- it's not like 9
or 10 is going to stop warning about malformed HTML. Although I am not a
Math contributor/commiter, I support the change since going forward it will
On Thu, 01 May 2014 22:49:58 +0200, Thomas Neidhart wrote:
On 05/01/2014 10:31 PM, Gilles wrote:
Hi.
I don't like most of the changes performed on the Javadoc; most of
them
are going in the wrong direction IMHO, the most severe being the use
of
HTML entities rather than using MathJax.[1]
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML fragment.
Documentation writers need to remember that their content is being placed
within a bigger document so correct tag usage is important to get
predictable results.
I think all Math committers will find this thread
On Thu, 1 May 2014 16:10:09 -0500, Paul Benedict wrote:
Personally, I don't see a reason to revert the javadoc changes.
There's no
turning back the clock on the javadoc processing engine -- it's not
like 9
or 10 is going to stop warning about malformed HTML. Although I am
not a
Math
On Thu, 1 May 2014 16:31:13 -0500, Paul Benedict wrote:
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML
fragment.
Documentation writers need to remember that their content is being
placed
within a bigger document so correct tag usage is important to get
predictable
Correct tag usage for JavaDoc is properly formed HTML. HTML does not have
self-closing tags -- XHTML does. So if you want to have a proper HTML
document, you don't use self-closing tags.
By the way, HTML isn't legacy. HTML continues to evolve but XHTML is a
whole different beast. XML (also XHTML)
I have a compilation issue FYI, either with jdk6 or jdk7
JLouis
2014-05-01 18:43 GMT+02:00 Mark Struberg strub...@yahoo.de:
Hi!
I've looked at Continuum and it seems like it fails since weeks now.
Anyone successfully did run it with jdk-1.6?
If so, we should rather look at the
Le 01/05/2014 22:44, Gilles a écrit :
You are right.
In revision 1591770, I've removed this part of the unit test.
Thank you. ConcurrentHashMap has been revamped in Java 8, that explains
the issue.
Emmanuel Bourg
-
To
Le 01/05/2014 22:49, Thomas Neidhart a écrit :
* escape angle brackets (, ) with the corresponding HTML entities
Actually you only need to escape '', that may help a bit with the
readability.
Emmanuel Bourg
-
To
On Fri, 02 May 2014 00:23:33 +0200, Emmanuel Bourg wrote:
Le 01/05/2014 22:49, Thomas Neidhart a écrit :
* escape angle brackets (, ) with the corresponding HTML entities
Actually you only need to escape '', that may help a bit with the
readability.
In a context where people are fairly
Am Fri, 02 May 2014 00:49:53 +0200
schrieb Gilles gil...@harfang.homelinux.org:
In a context where people are fairly likely write documentation
referring to generics, it's quite short-sighted to impose rules that
lead to e.g. Listlt;String
IMO, that counts as _not_ readable.
You can use
+1
-Original Message-
From: Thomas Neidhart [mailto:thomas.neidh...@gmail.com]
Sent: Thursday, May 1, 2014 12:16 PM
To: dev@commons.apache.org
Subject: [VOTE] Release Math 3.3 based on RC2
Hi all,
I would like to call a vote to release Commons Math 3.3 based on RC2.
Changes since RC1:
On Thu, 1 May 2014 17:12:13 -0500, Paul Benedict wrote:
Correct tag usage for JavaDoc is properly formed HTML. HTML does
not have
self-closing tags -- XHTML does. So if you want to have a proper HTML
document, you don't use self-closing tags.
By the way, HTML isn't legacy. HTML continues to
On Fri, 2 May 2014 00:56:43 +0200, Bernd Eckenfels wrote:
Am Fri, 02 May 2014 00:49:53 +0200
schrieb Gilles gil...@harfang.homelinux.org:
In a context where people are fairly likely write documentation
referring to generics, it's quite short-sighted to impose rules that
lead to e.g.
On 5/1/14, 2:31 PM, Paul Benedict wrote:
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML fragment.
Documentation writers need to remember that their content is being placed
within a bigger document so correct tag usage is important to get
predictable results.
I
Phil, I don't know who was telling people Javadoc is XML. I never heard of
that. AFAIK, it has always been HTML but the Javadoc parser didn't care to
enforce it. Now it's enforcing it so the only good Javadoc is HTML as it
always was. If anyone wants to show me Sun saying Javadoc was XML, I'll
Hey JL, nice to know better to have details ;). When I checked yesterday
Mark didnt commit his work and the missing parts of my patch which should
be merged so I guess it will be fixed soon.
Le 1 mai 2014 23:18, Jean-Louis MONTEIRO jeano...@gmail.com a écrit :
I have a compilation issue FYI,
55 matches
Mail list logo
