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=15401projectId=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=15402projectId=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
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
2011/12/5 Sébastien Brisard sebastien.bris...@m4x.org:
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
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
On 5 December 2011 09:34, henrib hen...@apache.org 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
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 recorded
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
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
On 5 December 2011 10:50, henrib hen...@apache.org 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
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
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 {{WeightedN extends
Number}}?
Note that I am also concerned about domain-specific requirements (e.g. all
weights must be positive) that I would like to see
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 hen...@apache.org 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
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)
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
[+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
+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/
Easy one: +1.
Gary
On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote:
[+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
On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote:
[+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
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 simonetrip...@apache.org 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
On Mon, Dec 5, 2011 at 4:31 PM, Gary Gregory garydgreg...@gmail.com wrote:
On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier
grobme...@gmail.comwrote:
[+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 Mon, Dec 5, 2011 at 4:43 PM, sebb seb...@gmail.com wrote:
On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org 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
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
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 seb...@gmail.com wrote:
On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote:
Salut Henri,
if you
Hi Gary!
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory garydgreg...@gmail.com 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
On 5 December 2011 15:42, Gary Gregory garydgreg...@gmail.com 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
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory garydgreg...@gmail.com 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.
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:
+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
On 5 December 2011 16:46, henrib hen...@apache.org 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
On Mon, Dec 5, 2011 at 6:44 PM, ralph.goers @dslextreme.com
ralph.go...@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
On Mon, Dec 5, 2011 at 6:51 PM, sebb seb...@gmail.com wrote:
On 5 December 2011 16:46, henrib hen...@apache.org 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 ?
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 can
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 seb...@gmail.com wrote:
On 5
On 5 December 2011 18:30, ralph.goers @dslextreme.com
ralph.go...@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
On 5 December 2011 18:10, henrib hen...@apache.org 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
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:
On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
On 5 December 2011 18:10, henrib hen...@apache.org 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
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
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 gudnabr...@gmail.com 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,
On 5 December 2011 19:01, henrib hen...@apache.org 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
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 in
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 grobme...@gmail.com wrote:
On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com 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
On Sun, Dec 4, 2011 at 3:24 PM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
Am 03.12.2011 22:14, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
oliver.he...@oliver-heger.de**wrote:
Am 03.12.2011 17:18, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 5:45 AM, Oliver
My +1.
Gary
On Fri, Dec 2, 2011 at 10:06 PM, Gary Gregory ggreg...@apache.org 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
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
On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote:
On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com
wrote:
On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote:
I think all that Sebastian is saying is something like if you can
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 aggregate
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 changes
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(),
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 loose of
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 :-)...)
... and you
On Mon, Dec 5, 2011 at 5:13 PM, Christian Grobmeier grobme...@gmail.comwrote:
On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote:
On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com
wrote:
On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson
On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier grobme...@gmail.com wrote:
On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote:
On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com
wrote:
On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson
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:
On Mon, Dec 5, 2011 at 5:19 PM, Jörg Schaible joerg.schai...@gmx.de 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
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 improvement!
On Mon, Dec 5, 2011 at 5:45 PM, Jörg Schaible joerg.schai...@gmx.de 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
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
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 grobme...@gmail.com
wrote:
On Mon, Dec 5,
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 sebastien.bris...@m4x.org:
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
70 matches
Mail list logo
