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
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 i
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 Sq
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
On 4 December 2011 19:57, henrib 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.
>>
>>
>
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15386&projectId=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 N
- 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.
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:
When building I get a heap space error in testSpeedCheck(org.apache.**
commons.codec.language.bm.
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 belie
On 4 December 2011 19:08, Henri Biestro (Created) (JIRA)
wrote:
> Redesign API for stability
> --
>
> Key: JEXL-123
> URL: https://issues.apache.org/jira/browse/JEXL-123
> Project: Commons JEXL
> Issue Type: Improvement
>
+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:
http://apache-commons.680414.n4.nabble.com/JEXL-PreVOTE
+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 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
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
On 4 December 2011 18:46, henrib 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 anyon
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 de
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 f
On 4 December 2011 17:13, William Speirs 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 wait until 2.0 to
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 wrote:
> On 3 December 2011 1
On 4 December 2011 10:41, henrib 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 convention allow the p
On 3 December 2011 18:11, Gary Gregory wrote:
> On Sat, Dec 3, 2011 at 12:04 PM, William Speirs 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 java.sql.SQLXML which was introduced in Java
On 3 December 2011 14:52, henrib 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
compatibility, but I thi
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 i
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 declar
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
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:
http://apach
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.
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, 2011,
27 matches
Mail list logo
