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
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
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,
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
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
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: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 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 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 "
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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 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
+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
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-
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
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
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
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
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
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
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
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 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
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 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
>
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
+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
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] 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
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
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
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...
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
-
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.
71 matches
Mail list logo
