Hi,
for some reason, this committ
>
> URL: http://svn.apache.org/viewvc?rev=1210359&view=rev
> Log:
> - Corrected expressions for mean and variance in
> distribution.PascalDistribution (MATH-715).
> - Made javadoc more explicit
> - Restored SVN properties to various files in package distribution.
Hi Mikkel,
>
> No, you are more than welcome to do the patch and I'll review it :-). Thanks!
>
> Cheers, Mikkel.
>
I've committed a correction (r1210359). Could you please review it and
post your comments on the JIRA ticket (MATH-715).
Thanks a lot!
Sébastien
-
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15401&projectId=79
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 5 Dec 2011 08:21:42 +
Finished at: Mon 5 Dec 2011 08:24:19 +
Total time: 2m 37s
Build Trigger: Schedule
Build
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15402&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 5 Dec 2011 08:24:38 +
Finished at: Mon 5 Dec 2011 08:28:46 +
Total time: 4m 7s
Build Trigger: Schedule
Build N
Hi Claudio,
what a pleasant surprise! :) I was hoping commons-graph would have
caught the interest of researchers on that field, I'm really happy you
would like to contribute!
I agree with your observations, please fill new issues on JIRA[1] and
feel free to provide patches, I'll process them ASAP
2011/12/5 Sébastien Brisard :
> Hi Mikkel,
>>
>> No, you are more than welcome to do the patch and I'll review it :-). Thanks!
>>
>> Cheers, Mikkel.
>>
> I've committed a correction (r1210359). Could you please review it and
> post your comments on the JIRA ticket (MATH-715).
> Thanks a lot!
> Séba
Sebb;
Lets not return the pb; Java6 is not downwards compatible with Java 1.5.
There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that
@Override can not be used on interfaces implementation, that addAll is not
there, a cost in switching environments before using mvn and publish
On 5 December 2011 09:34, henrib wrote:
> Sebb;
> Lets not return the pb; Java6 is not downwards compatible with Java 1.5.
Of course not; that's the point.
> There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that
> @Override can not be used on interfaces implementation, tha
Hi Mikkel,
>
> This is not to bash, but merely to try to
> stress the importance of keeping a stringent svn history.
>
> Cheers, Mikkel.
>
Thanks for pointing that out. I have run into numerous problems with
SVN this morning, and, although I'm sure I've committed with a log
(it's actually still rec
Hi Mikkel,
> It seems like only the test was changed in r1210359 (svn diff -r
> 1210359). This does _not_ correspond to the log (svn log -r 1210359).
Here is an excerpt of the email sent automatically when I committed
revision 1210359
==BEGIN EXCERPT==
Author: celestin
Date: Mon D
Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
processing), JSR-199 (compiler API).
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160017.html
Sent from the Commons - Dev mailing list
On 5 December 2011 10:50, henrib wrote:
> Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
> processing),
JUnit4 relies on annotations, but does not require Java 1.6
> JSR-199 (compiler API).
I think we need a bit more info than that.
What are the new features that will requ
Hi,
thanks to both for your words! Please find comments below.
On 05/12/2011 10:01, Simone Tripodi wrote:
Hi Claudio,
what a pleasant surprise! :) I was hoping commons-graph would have
caught the interest of researchers on that field, I'm really happy you
would like to contribute!
I agree with
Hi Claudio,
so nice to see you are already deep in the spirit of the project! :)
> As for my suggestion on types, should I go for {{Weighted Number>}}?
> Note that I am also concerned about domain-specific requirements (e.g. all
> weights must be positive) that I would like to see implemented as
>
JSR-269: custom annotation processing hooks are available in Java6; say
someones wants to develop an IDE plugin that checks whether usage of a
class/field/method annotated by @internal is made from the same package and
issue a warning in that case...
JSR-199: convert a script / or part of a script
On 5 December 2011 13:34, henrib wrote:
> JSR-269: custom annotation processing hooks are available in Java6; say
> someones wants to develop an IDE plugin that checks whether usage of a
> class/field/method annotated by @internal is made from the same package and
> issue a warning in that case...
Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
little forward...
Since a 2-person opposition never breaks the tie, a vote is in order to
decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
can actually break loose of Java 1.5 compatibility. (sic)
J
Salut Henri,
if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
users, I would be +1.
We recently accepted Java6 in Apache Cocoon since Oracle announced
Java 5 SE EOL (End Of Life) since 2009.
Anyway I would to point you to a message in the ASF Tika ML[1] where
describing the p
> [+1] Yes, you may release the next major release of JEXL3 with a Java6
> requirement
I think the maintainers of a component can decide on their own which
jdk they want to support. If you want to support a newer Java with the
next big major version of JEXL I give you my +1. For me a major
version
Henri,
I would love to see this as a Commons recommendation on the Wiki.
As Stefan mentioned, in Compress we have @experimental annons (I
actually added them).
I like the idea to make up a public, rarely to break interface api and
some not so public sometimes to break implementation. Maybe we shou
+1 Christian this is a nice idea - maybe RetentionPolicy.SOURCE
annotations? (so we don't have to bring the dependency in each
component for runtime...)
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On
Easy one: +1.
Gary
On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier wrote:
> > [+1] Yes, you may release the next major release of JEXL3 with a Java6
> > requirement
>
> I think the maintainers of a component can decide on their own which
> jdk they want to support. If you want to support a
On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier wrote:
> > [+1] Yes, you may release the next major release of JEXL3 with a Java6
> > requirement
>
> I think the maintainers of a component can decide on their own which
> jdk they want to support. If you want to support a newer Java with the
>
Personally, I do not like annotations to describe the stability of an API.
If it's public I can use it. The next release is binary and/or source
compatible, just document how to migrate. No one is forcing me to upgrade.
If I upgrade, I am using a new pile of code and I must deal with that.
Using
On 5 December 2011 15:06, Simone Tripodi wrote:
> Salut Henri,
>
> if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
> users, I would be +1.
> We recently accepted Java6 in Apache Cocoon since Oracle announced
> Java 5 SE EOL (End Of Life) since 2009.
Cocoon is a slightly diff
On Mon, Dec 5, 2011 at 4:31 PM, Gary Gregory wrote:
> On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier
> wrote:
>
>> > [+1] Yes, you may release the next major release of JEXL3 with a Java6
>> > requirement
>>
>> I think the maintainers of a component can decide on their own which
>> jdk they
On Mon, Dec 5, 2011 at 4:43 PM, sebb wrote:
> On 5 December 2011 15:06, Simone Tripodi wrote:
>> Salut Henri,
>>
>> if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
>> users, I would be +1.
>> We recently accepted Java6 in Apache Cocoon since Oracle announced
>> Java 5 SE EOL
Forgot to add the vote will close in 72 hours, as per-usual rules.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161054.html
Sent from the Commons - Dev mailing list arch
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Dec 5, 2011 at 4:43 PM, sebb wrote:
> On 5 December 2011 15:06, Simone Tripodi wrote:
>> Salut Henri,
>>
>> if you need the Java6 APIs to provide a fre
Hi Gary!
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I u
On 5 December 2011 15:42, Gary Gregory wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
If your component is pa
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I upgrade, I
About the *internal* and @internal (package & annotation);
Of course if we could come up with a "binding" convention on the source
layout and package name for all projects, it would be really nice (i.e. the
*internal* package convention).
(Oh, a common pom where only the source/test/site would be
You summed it up pretty well;
Can we participate in moving forward - Java6 is not really the bleeding
edge... - or are we bound to remain on obsolete platforms with Commons ?
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-
+1 to the proposal.
As for moving out of commons I would expect that it would require a vote of
the Commons PMC with approval from the board. I don't know why it would
need to go through the incubator since it would have already performed
releases here, its IP would already be cleared and presumab
On 5 December 2011 16:46, henrib wrote:
> You summed it up pretty well;
> Can we participate in moving forward - Java6 is not really the bleeding
> edge... - or are we bound to remain on obsolete platforms with Commons ?
That is not a question I can answer, because it's not a simple
dichotomy (i
On Mon, Dec 5, 2011 at 6:44 PM, ralph.goers @dslextreme.com
wrote:
> +1 to the proposal.
>
> As for moving out of commons I would expect that it would require a vote of
> the Commons PMC with approval from the board. I don't know why it would
> need to go through the incubator since it would have
On Mon, Dec 5, 2011 at 6:51 PM, sebb wrote:
> On 5 December 2011 16:46, henrib wrote:
>> You summed it up pretty well;
>> Can we participate in moving forward - Java6 is not really the bleeding
>> edge... - or are we bound to remain on obsolete platforms with Commons ?
>
> That is not a question
sebb-2-2 wrote
>
> My view is that while there is still a need for software to be able to
> run on Java 1.5, we should not insist on requiring a minimum of
> 1.6.*unless* there is good technical reason for doing so.
>
But you don't consider a good (technical) reason the fact that the
contributor
FWIW, I have been planning on starting work on vfs3 when I finish up with
some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file
support, so vfs3 will be slimmed down to just provide implementations.
Ralph
On Mon, Dec 5, 2011 at 9:51 AM, sebb wrote:
> On 5 December 2011 16:4
On 5 December 2011 18:30, ralph.goers @dslextreme.com
wrote:
> FWIW, I have been planning on starting work on vfs3 when I finish up with
> some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file
> support, so vfs3 will be slimmed down to just provide implementations.
That's aga
On 5 December 2011 18:10, henrib wrote:
>
> sebb-2-2 wrote
>>
>> My view is that while there is still a need for software to be able to
>> run on Java 1.5, we should not insist on requiring a minimum of
>> 1.6.*unless* there is good technical reason for doing so.
>>
> But you don't consider a good
sebb-2-2 wrote
>
> Indeed, ideally everyone would now be using Java 6 and Windows users
> should all upgrade to Windows 7 etc.
>
But even if it were the case, you'd still argue for us to continue using
IE6...
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Can-
On Mon, Dec 5, 2011 at 7:38 PM, sebb wrote:
> On 5 December 2011 18:10, henrib wrote:
>> sebb-2-2 wrote
>>>
>>> My view is that while there is still a need for software to be able to
>>> run on Java 1.5, we should not insist on requiring a minimum of
>>> 1.6.*unless* there is good technical reaso
I think all that Sebastian is saying is something like "if you can
create your new, cool API and the only things you really miss from
Java 6 are @Override on interface implementation methods and
ServiceLoader, for example, maybe it's worth that tiny bit of extra
pain to reach that slightly larger a
Matt Benson-2 wrote
>
> ... maybe it's worth that tiny bit of extra pain to reach that slightly
> larger audience...
>
It is not a tiny bit when you accumulate it; and JEXL3 would not reach a
larger audience because it allows deployment on Java 1.5. This is a wrongly
imposed cost with no benefit
On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson wrote:
> I think all that Sebastian is saying is something like "if you can
> create your new, cool API and the only things you really miss from
> Java 6 are @Override on interface implementation methods and
> ServiceLoader, for example, maybe it's worth
On 5 December 2011 19:01, henrib wrote:
>
> sebb-2-2 wrote
>>
>> Indeed, ideally everyone would now be using Java 6 and Windows users
>> should all upgrade to Windows 7 etc.
>>
> But even if it were the case, you'd still argue for us to continue using
> IE6...
No, I would not; that's an end-user
sebb-2-2 wrote
>
>
>> But even if it were the case, you'd still argue for us to continue using
>> IE6...
>
> No, I would not; that's an end-user product.
>
>
I see it as the worst web app client platform... Even on that, we can't
agree!
(sorry, couldn't resist :-)...)
--
View this message
Hi folks,
I would like to call a vote to release commons-email-1.3 which contains
the following bug fixes and improvements found here
http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html
Tag:
https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2
On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier wrote:
> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson wrote:
>> I think all that Sebastian is saying is something like "if you can
>> create your new, cool API and the only things you really miss from
>> Java 6 are @Override on interface implemen
On Sun, Dec 4, 2011 at 3:24 PM, Oliver Heger
wrote:
> Am 03.12.2011 22:14, schrieb Gary Gregory:
>
>> On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
>> **wrote:
>>
>> Am 03.12.2011 17:18, schrieb Gary Gregory:
>>>
>>> On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
wrote:
Whe
My +1.
Gary
On Fri, Dec 2, 2011 at 10:06 PM, Gary Gregory wrote:
> Good day to you all:
>
> I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
> not calling it RC3 because there are no changes in source files from the
> last RC. The only difference is that I built from a
Hi Siegfried:
Thank you for preparing the RC.
This /sounds/ worrisome from RAT:
Unapproved licenses:
src/resources/META-INF/mime.types
src/test/eml/attachment-only.eml
src/test/eml/html-attachment.eml
src/test/eml/multipart-report.eml
src/test/eml/simple-reply.eml
src/test/eml/simpl
On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson wrote:
> On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier
> wrote:
>> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson wrote:
>>> I think all that Sebastian is saying is something like "if you can
>>> create your new, cool API and the only things you r
Hi Henri,
henrib wrote:
>
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
>
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggre
Gary Gregory wrote:
> Good day to you all:
>
> I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
> not calling it RC3 because there are no changes in source files from the
> last RC. The only difference is that I built from a fresh checkout of the
> RC2 svn tag.
>
> The c
Go for 2.1.
The problem of binary incompatibility only arise if you do *not* have access
to the sources.
sebb wrote:
> The Jexl 2.0 branch now has only a few incompatibilities reported by
> Clirr (see below).
>
> Also the 2.0.1 JUnit tests now run (with minor essential changes)
> against both
Note that in the testcase XML you don't need @params if you're using
the (boolean, double) constructor. The default constructor arguments
were needed to avoid the NPEs that were thrown due to the (Boolean,
Double) constructor calling { this( booleanProperty.booleanValue(),
doubleProperty.doubleVal
Hi Henri,
henrib wrote:
> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
> little forward...
>
> Since a 2-person opposition never breaks the tie, a vote is in order to
> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
> can actually break loo
henrib wrote:
>
> sebb-2-2 wrote
>>
>>
>>> But even if it were the case, you'd still argue for us to continue using
>>> IE6...
>>
>> No, I would not; that's an end-user product.
>>
>>
> I see it as the worst web app client platform... Even on that, we can't
> agree!
> (sorry, couldn't resist
On Mon, Dec 5, 2011 at 5:13 PM, Christian Grobmeier wrote:
> On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson wrote:
> > On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier
> wrote:
> >> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson
> wrote:
> >>> I think all that Sebastian is saying is something lik
On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier wrote:
> On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson wrote:
>> On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier
>> wrote:
>>> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson wrote:
I think all that Sebastian is saying is something like "
Hi Siegfried,
Siegfried Goeschl wrote:
> Hi folks,
>
> I would like to call a vote to release commons-email-1.3 which contains
> the following bug fixes and improvements found here
>
> http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-
report.html
>
> Tag:
>
> https://svn.apa
On Mon, Dec 5, 2011 at 5:19 PM, Jörg Schaible wrote:
> Gary Gregory wrote:
>
> > Good day to you all:
> >
> > I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
> > not calling it RC3 because there are no changes in source files from the
> > last RC. The only difference is
Hi Gary,
Gary Gregory wrote:
> Hi All:
>
> I've made several improvements to VFS over the last couple of months which
> feels ready for a release soon.
>
> One important internal change is that the builds runs almost all unit
> tests
> :)
I saw your efforts and this is really a great improvem
On Mon, Dec 5, 2011 at 5:45 PM, Jörg Schaible wrote:
> Hi Gary,
>
> Gary Gregory wrote:
>
> > Hi All:
> >
> > I've made several improvements to VFS over the last couple of months
> which
> > feels ready for a release soon.
> >
> > One important internal change is that the builds runs almost all u
With all the changes you've made a release of VFS is warranted.
I'm not sure why a renae would be required instead of just calling it VFS3. To
be honest, I've never much liked the VFS API, expecially the
ConfigurationBuilder stuff. Losing the API in favor of the Java API seems like
a good way t
I'm confused. Is this a vote thread or a discussion thread? So far I've only
seen +1 votes but I may have missed others with all the noise.
Ralph
On Dec 5, 2011, at 2:45 PM, Matt Benson wrote:
> On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier
> wrote:
>> On Mon, Dec 5, 2011 at 10:37 PM,
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
2011/12/5 Sébastien Brisard :
> Hi Mikkel,
>> It seems like only the test was changed in r1210359 (svn diff -r
>> 1210359). This does _not_ correspond to the log (svn log -r 1210359).
>
> Here is an excerpt of the email sent automatically when I committed
> revision 1210359
>
> ==BEGIN EXCE
71 matches
Mail list logo
