The part I'm struggling with is that if these are annotations vs just javadoc
tags then I would expect some kind of either compile time or runtime behavior
(or both). It seems that you are proposing javadoc tags instead? If not what
behavior would the annotations cause?
Ralph
On Dec 3,
On 2011-12-04, henrib wrote:
When trying to release JEXL 2.1, the API was disrupted and the clirr report
was outputing lots of clutter.
As the dev, it became very hard to understand whether the change was
actually breaking the intended stable API or just some internal methods or
class.
Stefan Bodewig wrote
Would you have known at the point when JEXL 2.0.1 has been released
which APIs you'd mark up as @stable or @usable?
Yes for most and in doubt, I could have marked them @usable (or @internal
which may be a better term).
--
View this message in context:
ralph.goers @dslextreme.com wrote
The part I'm struggling with is that if these are annotations vs just
javadoc tags then I would expect some kind of either compile time or
runtime behavior (or both). It seems that you are proposing javadoc tags
instead? If not what behavior would the
Keeping track as it evolves based on feedback;
Goal is to allow easy definition, usage and check of stable APIs.
An annotation and a package naming convention allow the project developer to
clearly state when a class/method/field is not part of the stable contract
despite a public/protected
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-exec-test has an issue affecting its community integration.
This
On 3 December 2011 14:52, henrib hen...@apache.org wrote:
If the last hurdle to binary compatibility is replacing DebugInfo by
JexlInfo, by all means, replace it!
OK, will do.
Nice analysis and great result.
Thanks.
At times it looked as though the changes were too great to restore
On 3 December 2011 18:11, Gary Gregory garydgreg...@gmail.com wrote:
On Sat, Dec 3, 2011 at 12:04 PM, William Speirs wspe...@apache.org wrote:
I took a look at the Continuum build error from Nov 26th and the error is
that adding getSQLXML() in BeanProcessor.java requires
importing
On 4 December 2011 10:41, henrib hen...@apache.org wrote:
Keeping track as it evolves based on feedback;
Goal is to allow easy definition, usage and check of stable APIs.
+1, agree that we need to be clearer about what the intended external API is.
An annotation and a package naming
What is the rule on when you can switch Java versions? Is going from
1.4 to 1.5 too small of a version number bump to require a different
version of Java? Would we need to wait until 2.0 to switch to Java
1.6?
Thanks...
Bill-
On Sun, Dec 4, 2011 at 11:03 AM, sebb seb...@gmail.com wrote:
On 3
On 4 December 2011 17:13, William Speirs wspe...@apache.org wrote:
What is the rule on when you can switch Java versions? Is going from
http://commons.apache.org/releases/versioning.html
1.4 to 1.5 too small of a version number bump to require a different
version of Java? Would we need to
As the subject says - how likely is it that users will have
implemented the Script interface?
There are no unit test cases that do (apart from the one I added to
check for binary compat).
Don't know if this is an indication that the unit tests are incomplete
or that there is not really a use case
sebb-2-2 wrote
Don't know if this is an indication that the unit tests are incomplete
or that there is not really a use case for implementing the interface,
(other than the implementations which are already supplied.)
I don't think anyone would implement the Script interface without
On 4 December 2011 18:46, henrib hen...@apache.org wrote:
sebb-2-2 wrote
Don't know if this is an indication that the unit tests are incomplete
or that there is not really a use case for implementing the interface,
(other than the implementations which are already supplied.)
I don't think
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 2.0.1 and 2.1-SNAPSHOT.
The remaining errors all relate to adding methods to interfaces.
According to the JLS [1], adding methods
+1 to release as 3.0, breaking any compat should be major. New package
seems safer but I would not -1 a release as is.
G
On Sun, Dec 4, 2011 at 1:59 PM, sebb seb...@gmail.com wrote:
The Jexl 2.0 branch now has only a few incompatibilities reported by
Clirr (see below).
Also the 2.0.1 JUnit
+1 :-)
I honestly believe it is safe and that we are not making a dis-service to
the Jexl community.
Thanks again for your hard efforts in keeping the package name as-is on
their behalf.
Best regards,
Henrib
--
View this message in context:
On 4 December 2011 19:08, Henri Biestro (Created) (JIRA)
j...@apache.org wrote:
Redesign API for stability
--
Key: JEXL-123
URL: https://issues.apache.org/jira/browse/JEXL-123
Project: Commons JEXL
Issue Type:
sebb-2-2 wrote
Since it is targeted at new projects or at least very active ones, the
deployment will require at least Java 1.6.
Now if 1.6 is absolutely required to support certain new features,
that is a different matter.
I should have said that 'not useful' too.
I believe it is
Am 03.12.2011 22:14, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
oliver.he...@oliver-heger.dewrote:
Am 03.12.2011 17:18, schrieb Gary Gregory:
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
oliver.he...@oliver-heger.de**wrote:
When building I get a heap space error in
- Mail original -
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 2.0.1 and 2.1-SNAPSHOT.
The remaining errors all relate to adding methods to interfaces.
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15386projectId=79
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 4 Dec 2011 22:20:35 +
Finished at: Sun 4 Dec 2011 22:21:35 +
Total time: 1m 0s
Build Trigger: Schedule
Build
On 4 December 2011 19:57, henrib hen...@apache.org wrote:
sebb-2-2 wrote
Since it is targeted at new projects or at least very active ones, the
deployment will require at least Java 1.6.
Now if 1.6 is absolutely required to support certain new features,
that is a different matter.
I
Hello,
I have been reading the source in the past days and I found that the
concept of weight (e.g. weighted edge, graph, etc) could benefit from
a bit of abstraction.
The basic idea would be to have an interface called Weighted with an
obvious method getWeight(). Changes in the code would
Welcome! Contributions (and the contributor) are always welcome. In my
past life, I did quite a bit of graph programming to solve business
problems. We used yfiles, though. I hope to get around to playing with
[graph] someday too. Please do submit a patch!
On Dec 4, 2011 6:43 PM, Claudio
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-exec-test has an issue affecting its community integration.
This
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
27 matches
Mail list logo
