Hi,
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
overwritten methos, so there is no need for @inheritDoc.
If all agree, one could drop this if the code is modified?
sounds good :-)
On Fri, Jul 22, 2011 at 6:18 AM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
From the responses in the Java5 thread I propose the following.
(1) Release current trunk minus a few lines of code I already added for
initial Zip64 support plus some minor changes ASAP as
On 22 July 2011 05:18, Stefan Bodewig bode...@apache.org wrote:
Hi all,
From the responses in the Java5 thread I propose the following.
(1) Release current trunk minus a few lines of code I already added for
initial Zip64 support plus some minor changes ASAP as 1.2
(2) Require Java5,
The BCEL code is still under the jakarta SVN tree, which means that
commit messages go to a Jakarta mailing list.
Surely we should move the code to Commons now?
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
sebb wrote:
The BCEL code is still under the jakarta SVN tree, which means that
commit messages go to a Jakarta mailing list.
Surely we should move the code to Commons now?
+1
-
To unsubscribe, e-mail:
+1
On Fri, Jul 22, 2011 at 10:53 AM, Jörg Schaible
joerg.schai...@scalaris.com wrote:
sebb wrote:
The BCEL code is still under the jakarta SVN tree, which means that
commit messages go to a Jakarta mailing list.
Surely we should move the code to Commons now?
+1
Done.
http://svn.apache.org/repos/asf/commons/proper/bcel/
On Fri, Jul 22, 2011 at 1:55 AM, Torsten Curdt tcu...@vafer.org wrote:
+1
On Fri, Jul 22, 2011 at 10:53 AM, Jörg Schaible
joerg.schai...@scalaris.com wrote:
sebb wrote:
The BCEL code is still under the jakarta SVN tree, which
Anyone adverse to me svn moving JCS over from Jakarta? It will mean
someone needing to update the site (which they should do while moving
that over).
Hen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
On 22 July 2011 10:33, Henri Yandell flame...@gmail.com wrote:
Anyone adverse to me svn moving JCS over from Jakarta? It will mean
someone needing to update the site (which they should do while moving
that over).
OK by me.
Also need to update Gump (and add it to Continuum) - I can take care
Hi!
Jakob Korherr (apacheId jakobk) is also interested and did some work in this
area in MyFaces and OWB already.
There are 2 main parts in this project
a.) A classpath scanner which does _not_ use Class.getDeclaredXxx etc, since
this allocates memory in the ClassLoader which cannot get freed
awesome ... thx!
On Fri, Jul 22, 2011 at 11:26 AM, Henri Yandell flame...@gmail.com wrote:
Done.
http://svn.apache.org/repos/asf/commons/proper/bcel/
On Fri, Jul 22, 2011 at 1:55 AM, Torsten Curdt tcu...@vafer.org wrote:
+1
On Fri, Jul 22, 2011 at 10:53 AM, Jörg Schaible
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
What's the svn url now?
On 07/22/2011 06:45 AM, Torsten Curdt wrote:
awesome ... thx!
On Fri, Jul 22, 2011 at 11:26 AM, Henri Yandellflame...@gmail.com wrote:
Done.
http://svn.apache.org/repos/asf/commons/proper/bcel/
On Fri, Jul 22, 2011 at 1:55 AM, Torsten Curdttcu...@vafer.org wrote:
https://svn.apache.org/repos/asf/commons/proper/bcel
On 22 July 2011 12:21, Dave Brosius dbros...@apache.org wrote:
What's the svn url now?
On 07/22/2011 06:45 AM, Torsten Curdt wrote:
awesome ... thx!
On Fri, Jul 22, 2011 at 11:26 AM, Henri Yandellflame...@gmail.com
wrote:
Done.
Hi Gary,
I'm having no joy reproducing your test failures against my patch to
CODEC-125. It's possibly something to do with our different platforms,
locales or tool-chains. However, I doubt we can make any progress with it by
us ping-ponging messages through the bug tracker. If it is OK with you,
On Thu, Jul 21, 2011 at 11:54 PM, Dave Brosius dbros...@apache.org wrote:
Found an collection type error when adding generics in this code below.
Collection was holding both ElementValueGen and ElementValue objects which
are unrelated by inheritance.
Modified code so only ElementValueGen are
On 7/21/11 9:30 PM, Matt Benson wrote:
First, Simo added [meiyo] to the sandbox. Now, some of the guys from
the various JEE-related communities have expressed interest in working
with class scanning here at Commons.
Great!
What we would propose to do is
start with the code of Geronimo's
Hi all guys!
That sounds really interesting!!!
I think that bringing the new ideas in existing [meiyo] APIs would
allow us releasing a new component soon!
Thanks in advance for your help and interesting, looking forward to
hear from you soon!!!
Simo
http://people.apache.org/~simonetripodi/
On 7/21/11 6:56 PM, Greg Sterijevski wrote:
If a pivoting QR decomp was to be included, I see it as existing in addition
to the current nonpivoting version. I don't see this as an addition to the
current QRDecompositionImpl. We would not be exposing more of the inner
workings of the
Hi Simo!
Yea, taking the best ideas of both projects (meiyo and xbean-finder) would
definitlely be a big bonus.
But to be honest: I think we should rather stay on the xbean-finder API. The
reason is that it's already heavily used in Geronimo, OpenEJB, OpenWebBeans and
a few other projects
On Fri, Jul 22, 2011 at 9:51 AM, Mark Struberg strub...@yahoo.de wrote:
Hi Simo!
Yea, taking the best ideas of both projects (meiyo and xbean-finder) would
definitlely be a big bonus.
But to be honest: I think we should rather stay on the xbean-finder API. The
reason is that it's already
Hi Mark!!!
For meiyo APIs I'd like to keep I mean end-user APIs; as Matt
suggested you, since you didn't hear about the already existing
sandbox component before, the most interesting parts of meiyo are the
filtering/callback APIs, expressed via EDSL. Have a look at the simple
included testcase[1]
Hoi Simo!
Yup, looks pretty fine from a users perspective. I'm just not sure if this can
be done in a performance intense scenario. We would need to do a few
performance tests upfront.
Remember we often have 50.000++ classes to scan through. And every Class has
~30 methods and fields w
On 22.07.11 11:33, Henri Yandell wrote:
Anyone adverse to me svn moving JCS over from Jakarta? It will mean
someone needing to update the site (which they should do while moving
that over).
I'd be willing to help, just need some directions.
I did some larger modifications to the code base
On Fri, Jul 22, 2011 at 12:10 PM, Thomas Vandahl t...@apache.org wrote:
On 22.07.11 11:33, Henri Yandell wrote:
Anyone adverse to me svn moving JCS over from Jakarta? It will mean
someone needing to update the site (which they should do while moving
that over).
I'd be willing to help, just
On the need for pivoting:
Here is my first approach for changing OLSMultipleRegression to do
constrained estimation:
public double[] calculateBeta(double[][] coeff, double[] rhs) {
if (rhs.length != coeff.length) {
throw new IllegalArgumentException();
}
Sorry,
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{}
should read:
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{
@Override
public void newSampleData(double[] data, double[][] coeff, double[] rhs,
int nob, int nvars) {
On Fri, Jul 22, 2011 at 5:33 AM, Henri Yandell flame...@gmail.com wrote:
Anyone adverse to me svn moving JCS over from Jakarta?
snip/
Not at all, thanks for both the svn moves Hen!
-Rahul
It will mean
someone needing to update the site (which they should do while moving
that over).
Hen
On Thu, Jul 21, 2011 at 9:08 AM, Christian Grobmeier
grobme...@gmail.com wrote:
On Thu, Jul 21, 2011 at 9:50 AM, Henri Yandell flame...@gmail.com wrote:
I think the argument is the other way. You should be explaining why
you wouldn't simply just move to Java 5.
+1 - Java 1.4 must die now.
Hi,
for reference https://issues.apache.org/jira/browse/COMPRESS-128
The bzip2 inputstream checks whether its wrapped input stream is
System.in before closing it. Do we want to add the same behavior to all
other implementations or do we want to remove it from the bzip2 one and
leave it to the
Hi,
I've moved some JIRA issues that are clear they'll need to break the API
to 2.0 and assigned a few JIRAs where a patch is available or I would
know how to implement them to 1.2 and 1.3.
Please review
Hallo Stefan!!!
I think it would be nice having also s pure Java implementation of the
Snappy[1] compression (the Google's compression), I found a Java
implementation[2] but it's JNI wrapper :/
WDYT? Unfortunately my C++ skills are horrible but I'm available to help :P
Alles gute!, all the best,
Hallo Stefan,
I personally like more the NoCloseStream approach, it would help
avoiding code redundancies (having the Sysout check pattern repeated
doesn't look nice IMHO)
HTH, have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Jul 23,
33 matches
Mail list logo
