Re: [all] Java 5 vs. 6
We actually did vote on this matter :-) "Can the next version major version of a project require Java6? (i.e. drop Java 1.5)" Result was "yes". http://apache-commons.680414.n4.nabble.com/RESULT-VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tt4176593.html Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/all-Java-5-vs-6-tp4376289p4378518.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Hi,
Le 11/02/2012 05:10, Bill Barker a écrit :
> While the development team has exploded for [MATH], maintaining
> Serializable interfaces is expensive and historically hasn't been kept
> up.
I don't agree.
Maintaining serialization maintainance is hard only if you want to be
able to deserialized with version n something that was serialized with
version p. This situation appears either if you use serialization for
long term storage or if you have a distributed application with two
parts using different levels. The first case is a wrong use of
serialization. The second case can be simply declared to be unsupported.
Apart from that, maintaining serialization is updating serialVersionId,
which we did (and IMHO it is no big deal if it is not done due to the
reasons explained in previous paragraph).
> So I would go for requiring the user to do something like:
>
> public class MyPolynomialSplineFunction extends
> PolynomialSplineFunction, implements Serializable {
> private static long serialVersionUID = ;
>
> // put non-default constructors here
> }
I'm not sure it scales with more than one level of aggregation. What
would happen if the user wants to serialize one of our top level objects
that itself embeds one of our lower level objects ?
>
> it is less than a minute to do this in eclipse, so it should be on the
> user for classes like this.
I am strongly in favor of putting Serialize where it can be put. Once
again, it's not an absolute rule which should be done in one sweep, it's
more a small low priority regular task to add serialize here and there
as we see.
Luc
>
> -Original Message- From: Gilles Sadowski
> Sent: Friday, February 10, 2012 11:40 AM
> To: dev@commons.apache.org
> Subject: [Math] Make everything "Serializable" ?
>
> Hi.
>
> This is an issue raised in relation to this JIRA ticket:
> https://issues.apache.org/jira/browse/MATH-742
>
> My position is that there should not be a discussion each time someone
> wants
> a class to be "Serializable". Ideally, the rule should be clear enough that
> the developer of a new class knows whether it should be made "Serializable"
> or not.
> Either we decide to not get in the way, ever, by making everything
> "Serializable", or we think that some classes should be "Serializable" and
> others should not, for some reason. [And IMHO that reason should be more
> substantial than someone opening a ticket saying "Please make this class
> Serializable because I need it".]
> However, because the second alternative is likely to generate exhausting
> debates not worth the energy, I shall stop even trying to defend this
> point-of-view. ;)
>
>
> Best regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
On 11 February 2012 09:26, Luc Maisonobe wrote:
> Hi,
>
> Le 11/02/2012 05:10, Bill Barker a écrit :
>> While the development team has exploded for [MATH], maintaining
>> Serializable interfaces is expensive and historically hasn't been kept
>> up.
>
> I don't agree.
>
> Maintaining serialization maintainance is hard only if you want to be
> able to deserialized with version n something that was serialized with
> version p. This situation appears either if you use serialization for
> long term storage or if you have a distributed application with two
> parts using different levels. The first case is a wrong use of
> serialization. The second case can be simply declared to be unsupported.
>
> Apart from that, maintaining serialization is updating serialVersionId,
> which we did (and IMHO it is no big deal if it is not done due to the
> reasons explained in previous paragraph).
There's a bit more to it than that.
If a class is updated to add new fields, these either need to be
serialisable themselves, or be marked transient.
And transient can only be used if the field is not needed until after
deserialisation.
Also, some consideration must be given to the serialised form, to
ensure it is appropriate.
Serialisation and final fields don't play well together.
>> So I would go for requiring the user to do something like:
>>
>> public class MyPolynomialSplineFunction extends
>> PolynomialSplineFunction, implements Serializable {
>> private static long serialVersionUID = ;
>>
>> // put non-default constructors here
>> }
>
> I'm not sure it scales with more than one level of aggregation. What
> would happen if the user wants to serialize one of our top level objects
> that itself embeds one of our lower level objects ?
Or indeed if PolynomialSplineFunction is final?
>>
>> it is less than a minute to do this in eclipse, so it should be on the
>> user for classes like this.
>
> I am strongly in favor of putting Serialize where it can be put. Once
> again, it's not an absolute rule which should be done in one sweep, it's
> more a small low priority regular task to add serialize here and there
> as we see.
Even without trying to maintain version compatibilty, adding
Serialisation can be non-trivial.
It should also be tested - I don't think there are any unit tests yet.
> Luc
>
>>
>> -Original Message- From: Gilles Sadowski
>> Sent: Friday, February 10, 2012 11:40 AM
>> To: dev@commons.apache.org
>> Subject: [Math] Make everything "Serializable" ?
>>
>> Hi.
>>
>> This is an issue raised in relation to this JIRA ticket:
>> https://issues.apache.org/jira/browse/MATH-742
>>
>> My position is that there should not be a discussion each time someone
>> wants
>> a class to be "Serializable". Ideally, the rule should be clear enough that
>> the developer of a new class knows whether it should be made "Serializable"
>> or not.
>> Either we decide to not get in the way, ever, by making everything
>> "Serializable", or we think that some classes should be "Serializable" and
>> others should not, for some reason. [And IMHO that reason should be more
>> substantial than someone opening a ticket saying "Please make this class
>> Serializable because I need it".]
>> However, because the second alternative is likely to generate exhausting
>> debates not worth the energy, I shall stop even trying to defend this
>> point-of-view. ;)
>>
>>
>> Best regards,
>> Gilles
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Daemon 1.0.9 based on RC1
Am 10.02.2012 17:34, schrieb Luc Maisonobe: Le 10/02/2012 15:22, Mladen Turk a écrit : On 02/07/2012 01:52 PM, Mladen Turk wrote: Votes, please. This vote will close in 72 hours [X] +1 Release Daemon 1.0.9 [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Just to record my vote. Since 72 hour period exceeded, suppose I'll just declare this release as not passed cause I was not been able to collect enough +1 votes. Sorry, I missed that. +1 from me (despite the lack of test slightly bothers me). Hey, I'm new to commons and I'm wondering why you vote +1, if something bothers you. I thought that is, what +0 is for?! Regards (and sorry for off-topic), Benedikt Luc Regards - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Daemon 1.0.9 based on RC1
Bene, have a look at http://www.apache.org/foundation/voting.html -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Feb 11, 2012 at 1:17 PM, Benedikt Ritter wrote: > Am 10.02.2012 17:34, schrieb Luc Maisonobe: > >> Le 10/02/2012 15:22, Mladen Turk a écrit : >>> >>> On 02/07/2012 01:52 PM, Mladen Turk wrote: Votes, please. This vote will close in 72 hours [X] +1 Release Daemon 1.0.9 [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... >>> >>> Just to record my vote. >>> >>> Since 72 hour period exceeded, suppose I'll just >>> declare this release as not passed cause I was not been >>> able to collect enough +1 votes. >> >> >> Sorry, I missed that. >> >> +1 from me (despite the lack of test slightly bothers me). > > > Hey, I'm new to commons and I'm wondering why you vote +1, if something > bothers you. I thought that is, what +0 is for?! > > Regards (and sorry for off-topic), > Benedikt > > >> >> Luc >> >>> >>> >>> Regards >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Le 11/02/2012 11:25, sebb a écrit :
> On 11 February 2012 09:26, Luc Maisonobe wrote:
>> Hi,
>>
>> Le 11/02/2012 05:10, Bill Barker a écrit :
>>> While the development team has exploded for [MATH], maintaining
>>> Serializable interfaces is expensive and historically hasn't been kept
>>> up.
>>
>> I don't agree.
>>
>> Maintaining serialization maintainance is hard only if you want to be
>> able to deserialized with version n something that was serialized with
>> version p. This situation appears either if you use serialization for
>> long term storage or if you have a distributed application with two
>> parts using different levels. The first case is a wrong use of
>> serialization. The second case can be simply declared to be unsupported.
>>
>> Apart from that, maintaining serialization is updating serialVersionId,
>> which we did (and IMHO it is no big deal if it is not done due to the
>> reasons explained in previous paragraph).
>
> There's a bit more to it than that.
>
> If a class is updated to add new fields, these either need to be
> serialisable themselves, or be marked transient.
> And transient can only be used if the field is not needed until after
> deserialisation.
Yes, but checkstyle helps a lot detecting this.
> Also, some consideration must be given to the serialised form, to
> ensure it is appropriate.
I don't understand, can you explain a little more ?
>
> Serialisation and final fields don't play well together.
>
>>> So I would go for requiring the user to do something like:
>>>
>>> public class MyPolynomialSplineFunction extends
>>> PolynomialSplineFunction, implements Serializable {
>>> private static long serialVersionUID = ;
>>>
>>> // put non-default constructors here
>>> }
>>
>> I'm not sure it scales with more than one level of aggregation. What
>> would happen if the user wants to serialize one of our top level objects
>> that itself embeds one of our lower level objects ?
>
> Or indeed if PolynomialSplineFunction is final?
>
>>>
>>> it is less than a minute to do this in eclipse, so it should be on the
>>> user for classes like this.
>>
>> I am strongly in favor of putting Serialize where it can be put. Once
>> again, it's not an absolute rule which should be done in one sweep, it's
>> more a small low priority regular task to add serialize here and there
>> as we see.
>
> Even without trying to maintain version compatibilty, adding
> Serialisation can be non-trivial.
>
> It should also be tested - I don't think there are any unit tests yet.
All step handlers in the ODE package are tested for serialization, as
well as EmpiricalDistribution and the various descriptive statistics
classes, polynomial function, complex, fractions, vectors, matrices ...
There are even dedicated methods in TestUtils: serializeAndRecover and
checkSerializedEquality.
Luc
>
>> Luc
>>
>>>
>>> -Original Message- From: Gilles Sadowski
>>> Sent: Friday, February 10, 2012 11:40 AM
>>> To: dev@commons.apache.org
>>> Subject: [Math] Make everything "Serializable" ?
>>>
>>> Hi.
>>>
>>> This is an issue raised in relation to this JIRA ticket:
>>> https://issues.apache.org/jira/browse/MATH-742
>>>
>>> My position is that there should not be a discussion each time someone
>>> wants
>>> a class to be "Serializable". Ideally, the rule should be clear enough that
>>> the developer of a new class knows whether it should be made "Serializable"
>>> or not.
>>> Either we decide to not get in the way, ever, by making everything
>>> "Serializable", or we think that some classes should be "Serializable" and
>>> others should not, for some reason. [And IMHO that reason should be more
>>> substantial than someone opening a ticket saying "Please make this class
>>> Serializable because I need it".]
>>> However, because the second alternative is likely to generate exhausting
>>> debates not worth the energy, I shall stop even trying to defend this
>>> point-of-view. ;)
>>>
>>>
>>> Best regards,
>>> Gilles
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.or
Re: [VOTE] Release Daemon 1.0.9 based on RC1
Le 11/02/2012 13:17, Benedikt Ritter a écrit : > Am 10.02.2012 17:34, schrieb Luc Maisonobe: >> Le 10/02/2012 15:22, Mladen Turk a écrit : >>> On 02/07/2012 01:52 PM, Mladen Turk wrote: Votes, please. This vote will close in 72 hours [X] +1 Release Daemon 1.0.9 [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... >>> >>> Just to record my vote. >>> >>> Since 72 hour period exceeded, suppose I'll just >>> declare this release as not passed cause I was not been >>> able to collect enough +1 votes. >> >> Sorry, I missed that. >> >> +1 from me (despite the lack of test slightly bothers me). > > Hey, I'm new to commons and I'm wondering why you vote +1, if something > bothers you. I thought that is, what +0 is for?! Yes, but in this vote case we are short of +1 and the concern is really minor since we already known this component is well used and tested. Luc > > Regards (and sorry for off-topic), > Benedikt > >> >> Luc >> >>> >>> >>> Regards >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
On 11 February 2012 12:29, Luc Maisonobe wrote:
> Le 11/02/2012 11:25, sebb a écrit :
>> On 11 February 2012 09:26, Luc Maisonobe wrote:
>>> Hi,
>>>
>>> Le 11/02/2012 05:10, Bill Barker a écrit :
While the development team has exploded for [MATH], maintaining
Serializable interfaces is expensive and historically hasn't been kept
up.
>>>
>>> I don't agree.
>>>
>>> Maintaining serialization maintainance is hard only if you want to be
>>> able to deserialized with version n something that was serialized with
>>> version p. This situation appears either if you use serialization for
>>> long term storage or if you have a distributed application with two
>>> parts using different levels. The first case is a wrong use of
>>> serialization. The second case can be simply declared to be unsupported.
>>>
>>> Apart from that, maintaining serialization is updating serialVersionId,
>>> which we did (and IMHO it is no big deal if it is not done due to the
>>> reasons explained in previous paragraph).
>>
>> There's a bit more to it than that.
>>
>> If a class is updated to add new fields, these either need to be
>> serialisable themselves, or be marked transient.
>> And transient can only be used if the field is not needed until after
>> deserialisation.
>
> Yes, but checkstyle helps a lot detecting this.
Checkstyle (and Findbugs) warn you if the field is not serialisable.
Do they also warn you if a transient field is not set by deserialisation?
[Cannot remember offhand]
Even if so, each such report would have to be investigated to
establish whether it is OK to omit the field init or not, and if it is
OK to omit, this would need to be documented and the checkstyle config
updated to skip the warning.
>> Also, some consideration must be given to the serialised form, to
>> ensure it is appropriate.
>
> I don't understand, can you explain a little more ?
The default serialised form effectively copies the physical
representation of an object.
For simple objects that works fine, but for some data structures it
may be totally unsuitable.
An example from Effective Java [Bloch] is of a class that implements a
double-linked list of Strings.
The links are a big (and unnecessary) overhead on the serialised form;
only the Strings themselves really need to be passed across.
[The simple approach is to serialise the count, followed by the Strings].
Using the default serialisation will be a lot slower and may even
cause stack overflow as the default implementation uses recursive
traversal of the links.
Another example - serialising a hash table: hashes are not guaranteed
portable, so the deserialised form may be corrupt.
There's also the issue that de-serialisation does not use the
constructor, so any invariants which are established by the ctor (e.g.
non-null parameter) also need to be maintained by the readObject
method.
>>
>> Serialisation and final fields don't play well together.
>>
So I would go for requiring the user to do something like:
public class MyPolynomialSplineFunction extends
PolynomialSplineFunction, implements Serializable {
private static long serialVersionUID = ;
// put non-default constructors here
}
>>>
>>> I'm not sure it scales with more than one level of aggregation. What
>>> would happen if the user wants to serialize one of our top level objects
>>> that itself embeds one of our lower level objects ?
>>
>> Or indeed if PolynomialSplineFunction is final?
>>
it is less than a minute to do this in eclipse, so it should be on the
user for classes like this.
>>>
>>> I am strongly in favor of putting Serialize where it can be put. Once
>>> again, it's not an absolute rule which should be done in one sweep, it's
>>> more a small low priority regular task to add serialize here and there
>>> as we see.
>>
>> Even without trying to maintain version compatibilty, adding
>> Serialisation can be non-trivial.
>>
>> It should also be tested - I don't think there are any unit tests yet.
>
> All step handlers in the ODE package are tested for serialization, as
> well as EmpiricalDistribution and the various descriptive statistics
> classes, polynomial function, complex, fractions, vectors, matrices ...
>
> There are even dedicated methods in TestUtils: serializeAndRecover and
> checkSerializedEquality.
OK, I'd not noticed those.
However, adding Serializable still means devising and implementing the
appropriate unit tests.
==
I'm not saying don't do it, just that it involves a lot more work than
might be obvious initially.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed
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 issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 23 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.025 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.033 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.028 ms Process completed in 2005 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2004 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8017 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.895 sec <<< FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Sat Feb 11 14:11:57 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06001211022012, vmgump.apache.org:vmgump:06001211022012 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18666&projectId=75 Build statistics: State: Failed Previous State: Ok Started at: Sat 11 Feb 2012 15:20:10 + Finished at: Sat 11 Feb 2012 15:20:45 + Total time: 34s Build Trigger: Schedule Build Number: 161 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Sat 11 Feb 2012 14:41:14 + Comment: moving test sources to core module main dir Files changed: /commons/proper/digester/trunk/core/src/test (from /commons/proper/digester/trunk/src/test:1243073) ( 1243074 ) /commons/proper/digester/trunk/src/test ( 1243074 ) Changed: simonetripodi @ Sat 11 Feb 2012 14:43:33 + Comment: moving main resources to core module main dir Files changed: /commons/proper/digester/trunk/core/src/main/resources (from /commons/proper/digester/trunk/src/main/resources:1243074) ( 1243075 ) /commons/proper/digester/trunk/src/main/resources ( 1243075 ) Changed: simonetripodi @ Sat 11 Feb 2012 14:48:07 + Comment: main pom converted in a multi-module parent pom Files changed: /commons/proper/digester/trunk/pom.xml ( 1243077 ) Changed: simonetripodi @ Sat 11 Feb 2012 14:55:46 + Comment: first checkin of core module pom Files changed: /commons/proper/digester/trunk/core/pom.xml ( 1243079 ) Changed: simonetripodi @ Sat 11 Feb 2012 15:19:33 + Comment: fixing multi modules references in pom Files changed: /commons/proper/digester/trunk/annotations-processor/pom.xml ( 1243081 ) /commons/proper/digester/trunk/core/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/annotations/atom/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/api/addressbook/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/api/catalog/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/api/dbinsert/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/api/document-markup/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/edsl/atom/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/plugins/pipeline/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/rss/pom.xml ( 1243081 ) /commons/proper/digester/trunk/examples/xmlrules/addressbook/pom.xml ( 1243081 ) /commons/proper/digester/trunk/pom.xml ( 1243081 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
Interesting that you say that because long-term storage of data and communication between distributed components are exactly what I use serialization for. Note that communication between components almost automatically implies version mismatch in lots of production systems exactly because you can't update all components simultaneously. Systems like Avro, Thrift, Protobufs and Kryo all exist precisely because native serialization is so terribly broken. On Sat, Feb 11, 2012 at 1:26 AM, Luc Maisonobe wrote: > Maintaining serialization maintainance is hard only if you want to be > able to deserialized with version n something that was serialized with > version p. This situation appears either if you use serialization for > long term storage or if you have a distributed application with two > parts using different levels. The first case is a wrong use of > serialization. The second case can be simply declared to be unsupported. >
Re: [Math] Make everything "Serializable" ?
On Sat, Feb 11, 2012 at 08:31:53AM -0800, Ted Dunning wrote: > Interesting that you say that because long-term storage of data and > communication between distributed components are exactly what I use > serialization for. Note that communication between components almost > automatically implies version mismatch in lots of production systems > exactly because you can't update all components simultaneously. > > Systems like Avro, Thrift, Protobufs and Kryo all exist precisely because > native serialization is so terribly broken. Do you mean that you use a broken system for long-term storage? Gilles > On Sat, Feb 11, 2012 at 1:26 AM, Luc Maisonobe wrote: > > > Maintaining serialization maintainance is hard only if you want to be > > able to deserialized with version n something that was serialized with > > version p. This situation appears either if you use serialization for > > long term storage or if you have a distributed application with two > > parts using different levels. The first case is a wrong use of > > serialization. The second case can be simply declared to be unsupported. > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
> [...] > > However, adding Serializable still means devising and implementing the > appropriate unit tests. > > == > > I'm not saying don't do it, just that it involves a lot more work than > might be obvious initially. [Oh, I said that I would not fight over this... :-#] But the arguments here make me raise at least a -0 on having a liberal use of "implements Serializable". That would be a virtual -1 if we think that a lot of resources are to be devoted to make (and check that) everything works as advertised by the "Serializable" contract. [I still have to understand why objects that represent mathematical algorithms must be serializable. It is quite possible that I miss somehing but a use-case would help. In principle, I'd think that we must provide accessors that would enable user code to re-construct any CM object; then it's up to the user code to create any "Serializable" object for storing those data they want to send over the wire, and reconstruct the CM object on the other end...] Best, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
On 02/11/2012 06:46 PM, Gilles Sadowski wrote: [I still have to understand why objects that represent mathematical algorithms must be serializable. It is quite possible that I miss somehing but a use-case would help. In principle, I'd think that we must provide accessors that would enable user code to re-construct any CM object; then it's up to the user code to create any "Serializable" object for storing those data they want to send over the wire, and reconstruct the CM object on the other end...] I think you have a good point in general, but the case where this discussion started is not as clear-cut as this. In fact, many algorithms in CM are a mixture of data structures and algorithms bound together using OO paradigms, which may not be always the best solution. So my conclusion would be to work on improving the code to be more functional and separate algorithms / data. In the mean time we can support the users by making their lives easier and support serialization by default where possible. If somebody has to work on a use-case that requires more sophisticated methods, well, he/she will have to find a solution anyway. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[codec]Bug or Feature
Hi,
from BaseNCodec.java:
how does resizeBuffer() know how big 'int size' is? Bug or Feature?
/**
* Ensure that the buffer has room for size bytes
*
* @param size minimum spare space required
*/
protected void ensureBufferSize(int size){
if ((buffer == null) || (buffer.length < pos + size)){
resizeBuffer();
}
}
Regards
Andreas
--
Andreas Menke
Diplom-Informatiker Univ.
Software-Entwicklung
Fon 0151 5081 1173
Mail asme...@snafu.de
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec]Bug or Feature
looks wrong to me as well.
On 02/11/2012 12:01 PM, Andreas Menke wrote:
Hi,
from BaseNCodec.java:
how does resizeBuffer() know how big 'int size' is? Bug or Feature?
/**
* Ensure that the buffer has room for size bytes
*
* @param size minimum spare space required
*/
protected void ensureBufferSize(int size){
if ((buffer == null) || (buffer.length < pos + size)){
resizeBuffer();
}
}
Regards
Andreas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Lang - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18675&projectId=95 Build statistics: State: Failed Previous State: Failed Started at: Sat 11 Feb 2012 19:42:31 + Finished at: Sat 11 Feb 2012 19:42:59 + Total time: 27s Build Trigger: Schedule Build Number: 272 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: mbenson @ Sat 11 Feb 2012 18:57:19 + Comment: test same prefix/suffix Files changed: /commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/StrSubstitutorTest.java ( 1243121 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec]Bug or Feature
Hi Andreas,
Feel free to provide a test and a patch ;)
Gary
On Feb 11, 2012, at 13:39, Andreas Menke wrote:
> Hi,
>
> from BaseNCodec.java:
>
> how does resizeBuffer() know how big 'int size' is? Bug or Feature?
>
>/**
> * Ensure that the buffer has room for size bytes
> *
> * @param size minimum spare space required
> */
>protected void ensureBufferSize(int size){
>if ((buffer == null) || (buffer.length < pos + size)){
>resizeBuffer();
>}
>}
>
> Regards
>
> Andreas
>
> --
>
>
> Andreas Menke
>
> Diplom-Informatiker Univ.
> Software-Entwicklung
>
> Fon 0151 5081 1173
> Mail asme...@snafu.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Hi, Maybe one last effort can be made to come up with more understandable names (e.g. for a user that does not know what a Semigroup or Monoid is). Suggestions are welcome. I exhume this thread because I am still convinced that the "weight architecture" would benefit from a bit of renaming. It is probably not the case to touch mathematical concepts (Semigroup, Monoid), but rather the actual implementations and/or variable names. Consider that with the current fluent API the user has to deal with this stuff explicitly, specifying the appropriate "handler" for weights. So for example all primitive implementations[1] would change their name from FooWeight to something like FooWeightHandler, or FooWeightOperations, or something like that. Variable names (like in [2]) would change from e.g. orderedMonoid to weightHandler, weightOperations, etc. Any preference? Ciao Claudio [1] http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/ [2] line 64: http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
On Sat, Feb 11, 2012 at 07:35:25PM +0100, Thomas Neidhart wrote: > On 02/11/2012 06:46 PM, Gilles Sadowski wrote: > > >[I still have to understand why objects that represent mathematical > >algorithms must be serializable. It is quite possible that I miss somehing > >but a use-case would help. In principle, I'd think that we must provide > >accessors that would enable user code to re-construct any CM object; then > >it's up to the user code to create any "Serializable" object for storing > >those data they want to send over the wire, and reconstruct the CM object > >on the other end...] > > I think you have a good point in general, but the case where this > discussion started is not as clear-cut as this. In fact, many > algorithms in CM are a mixture of data structures and algorithms > bound together using OO paradigms, which may not be always the best > solution. When I mentioned data vs algorithms, I did not mean the "data" (instance variables) that is part of the algorithm which in an OO approach, you bundle together with the methods that operate on them. I think that it is possible to distinguish objects which primarily represent a (user-level) "data" structure from objects that represent algorithms (e.g. something which is aimed a producing a result later on). An example of the former would be an "Array2DRowRealMatrix" (from package "linear"), an example of the latter would be a "Gaussian" (from package "analysis.function"). While it is reasonable (IMO) to expect to serialize a matrix (a "data" structure), it is not so for a "function"; the fact that it can contain instance variables is due to an OO-programming feature, not to the concept itself. > So my conclusion would be to work on improving the code to be more > functional and separate algorithms / data. In the mean time we can > support the users by making their lives easier and support > serialization by default where possible. If somebody has to work on > a use-case that requires more sophisticated methods, well, he/she > will have to find a solution anyway. I would not draw that conclusion. As a Java library, it would not be wise for CM to move away from the OO paradigm. People who choose or use Java are accustomed to this programming style (or, even, like it ;-). Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Ciao Claudio! I understand and agree with you about your doubts - I don't have a strong idea, anyway I wouldn't take the *Handler as first choice, since it does not drive users to an event-handler alike programming model, rather *Operations makes more sense... Let's take some time to think about it, excellent catch anyway :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella wrote: > Hi, > > >> Maybe one last effort can be made to come up with more understandable >> names (e.g. for a user that does not know what a Semigroup or Monoid is). >> Suggestions are welcome. > > > I exhume this thread because I am still convinced that the "weight > architecture" would benefit from a bit of renaming. It is probably not the > case to touch mathematical concepts (Semigroup, Monoid), but rather the > actual implementations and/or variable names. Consider that with the current > fluent API the user has to deal with this stuff explicitly, specifying the > appropriate "handler" for weights. > > So for example all primitive implementations[1] would change their name from > FooWeight to something like FooWeightHandler, or FooWeightOperations, or > something like that. Variable names (like in [2]) would change from e.g. > orderedMonoid to weightHandler, weightOperations, etc. > > Any preference? > > Ciao > Claudio > > [1] > http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/ > [2] line 64: > http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup > > > -- > Claudio Squarcella > PhD student at Roma Tre University > E-mail address: squar...@dia.uniroma3.it > Phone: +39-06-57333215 > Fax: +39-06-57333612 > http://www.dia.uniroma3.it/~squarcel > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18676&projectId=75 Build statistics: State: Failed Previous State: Failed Started at: Sat 11 Feb 2012 20:20:07 + Finished at: Sat 11 Feb 2012 20:20:40 + Total time: 33s Build Trigger: Schedule Build Number: 161 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Sat 11 Feb 2012 20:11:00 + Comment: fixed reactor sequence Files changed: /commons/proper/digester/trunk/examples/annotations/atom/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/api/addressbook/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/api/catalog/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/api/dbinsert/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/api/document-markup/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/edsl/atom/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/plugins/pipeline/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/rss/pom.xml ( 1243142 ) /commons/proper/digester/trunk/examples/xmlrules/addressbook/pom.xml ( 1243142 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18678&projectId=75 Build statistics: State: Failed Previous State: Failed Started at: Sat 11 Feb 2012 21:42:00 + Finished at: Sat 11 Feb 2012 21:42:43 + Total time: 42s Build Trigger: Schedule Build Number: 161 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Sat 11 Feb 2012 20:20:52 + Comment: no needs for a pom in examples Files changed: /commons/proper/digester/trunk/examples/pom.xml ( 1243144 ) Changed: simonetripodi @ Sat 11 Feb 2012 20:23:59 + Comment: core module specific plugins moved to proper pom Files changed: /commons/proper/digester/trunk/core/pom.xml ( 1243145 ) /commons/proper/digester/trunk/pom.xml ( 1243145 ) Changed: simonetripodi @ Sat 11 Feb 2012 20:26:41 + Comment: updated parent pom wagon-ssh extension no longer needed Files changed: /commons/proper/digester/trunk/pom.xml ( 1243147 ) Changed: simonetripodi @ Sat 11 Feb 2012 20:29:10 + Comment: bundle plugin moved to core pom only - no other module has the needs to be OSGi ready, since the annotations-processor will be a compile tool, and samples won't be deployed Files changed: /commons/proper/digester/trunk/core/pom.xml ( 1243148 ) /commons/proper/digester/trunk/pom.xml ( 1243148 ) Changed: simonetripodi @ Sat 11 Feb 2012 20:31:20 + Comment: fixed next release version in release notes Files changed: /commons/proper/digester/trunk/RELEASE-NOTES.txt ( 1243151 ) Changed: simonetripodi @ Sat 11 Feb 2012 20:33:48 + Comment: adding next release notes Files changed: /commons/proper/digester/trunk/RELEASE-NOTES.txt ( 1243153 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 207 Failures: 0 Errors: 0 Success Rate: 100 Total time: 2.616 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella < squar...@dia.uniroma3.it> wrote: > > Any preference? > Wouldn't it be better to use the same method signatures like in commons-math FieldElement? http://commons.apache.org/math/apidocs/org/apache/commons/math/FieldElement.html#reciprocal%28%29 reciprocal instead of inverse and add instead of append? -- Axel Kramer
Re: [Math] Make everything "Serializable" ?
On 02/11/2012 09:18 PM, Gilles Sadowski wrote: I would not draw that conclusion. As a Java library, it would not be wise for CM to move away from the OO paradigm. People who choose or use Java are accustomed to this programming style (or, even, like it ;-). sure, I did not want to give the impression that OO in general is bad, I just think that sometimes the OO idea is taken to the extreme and one spends too much time trying to fit everything into objects ;-). Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Hello Axel, Wouldn't it be better to use the same method signatures like in commons-math FieldElement? http://commons.apache.org/math/apidocs/org/apache/commons/math/FieldElement.html#reciprocal%28%29 reciprocal instead of inverse and add instead of append? yes that would work (inverse should be replaced with negate, not reciprocal). We actually thought of commons-math before: it would feel like home for our little stack of interfaces (Semigroup, Monoid, etc). However my question was more on the semantics for class and variable names. Any idea? Thank you :) Claudio -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://squarcella.com/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Ciao Claudio, > > yes that would work (inverse should be replaced with negate, not > reciprocal). We actually thought of commons-math before: it would feel like > home for our little stack of interfaces (Semigroup, Monoid, etc). > +1 > However my question was more on the semantics for class and variable names. > Any idea? > Not yet :( all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1243180 - in /commons/proper/jexl/trunk: RELEASE-NOTES.txt src/site/xdoc/changes.xml src/site/xdoc/reference/syntax.xml
On 12 February 2012 00:05, wrote: > Author: henrib > Date: Sun Feb 12 00:05:26 2012 > New Revision: 1243180 > > URL: http://svn.apache.org/viewvc?rev=1243180&view=rev > Log: > Added function to syntax; updated release notes and changes > > Modified: > commons/proper/jexl/trunk/RELEASE-NOTES.txt > commons/proper/jexl/trunk/src/site/xdoc/changes.xml > commons/proper/jexl/trunk/src/site/xdoc/reference/syntax.xml > > Modified: commons/proper/jexl/trunk/RELEASE-NOTES.txt > URL: > http://svn.apache.org/viewvc/commons/proper/jexl/trunk/RELEASE-NOTES.txt?rev=1243180&r1=1243179&r2=1243180&view=diff > == > --- commons/proper/jexl/trunk/RELEASE-NOTES.txt (original) > +++ commons/proper/jexl/trunk/RELEASE-NOTES.txt Sun Feb 12 00:05:26 2012 > @@ -38,11 +38,36 @@ Its goal is to expose scripting features > > Due to binary and source incompatibilities and the scope of modifications, > JEXL has moved to the org.apache.commons.jexl3 > package. > -However, this is a drop-in replacement through JSF-223 and casual code usage > should find strict equivalence between > +Also note that JEXL now requires Java 6. > +However, this is a drop-in replacement through JSF-223 and casual code usage > should find easy equivalence between > jexl-2.x and 3.x (besides the package name). s/JSF/JSR/ ? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18684&projectId=75 Build statistics: State: Failed Previous State: Failed Started at: Sun 12 Feb 2012 00:40:03 + Finished at: Sun 12 Feb 2012 00:41:12 + Total time: 1m 9s Build Trigger: Schedule Build Number: 161 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Sun 12 Feb 2012 00:18:28 + Comment: configured checkstyle per module Files changed: /commons/proper/digester/trunk/annotations-processor/pom.xml ( 1243184 ) /commons/proper/digester/trunk/checkstyle-suppressions.xml ( 1243184 ) /commons/proper/digester/trunk/core/checkstyle-suppressions.xml (from /commons/proper/digester/trunk/checkstyle-suppressions.xml:1243142) ( 1243184 ) /commons/proper/digester/trunk/core/pom.xml ( 1243184 ) /commons/proper/digester/trunk/pom.xml ( 1243184 ) Changed: simonetripodi @ Sun 12 Feb 2012 00:20:11 + Comment: annotations processor is targeted 1.6 Files changed: /commons/proper/digester/trunk/annotations-processor/pom.xml ( 1243185 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 207 Failures: 0 Errors: 0 Success Rate: 100 Total time: 4.7889996 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
In this case , I am more prone in an API to provide a Wrapper Class that provides a Serializable view , rather than make everything Serializable or not. Leandro A. Pezzente. On viernes, 10 de febrero de 2012 at 4:41 PM, Gilles Sadowski wrote:Hi. This is an issue raised in relation to this JIRA ticket: https://issues.apache.org/jira/browse/MATH-742 My position is that there should not be a discussion each time someone wants a class to be "Serializable". Ideally, the rule should be clear enough that the developer of a new class knows whether it should be made "Serializable" or not. Either we decide to not get in the way, ever, by making everything "Serializable", or we think that some classes should be "Serializable" and others should not, for some reason. [And IMHO that reason should be more substantial than someone opening a ticket saying "Please make this class Serializable because I need it".] However, because the second alternative is likely to generate exhausting debates not worth the energy, I shall stop even trying to defend this point-of-view. ;) Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
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-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 20 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 : XML to Java Object Configuration
- commons-digester3-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to
project name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/apache-commons/digester/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 15 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 57 resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 101 source files to
/srv/gump/public/workspace/apache-commons/digester/core/target/test-classes
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-44/plexus-container-default-1.0-alpha-44.pom
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-44/plexus-containers-1.0-alpha-44.pom
Downloading:
http://localhost:8192/maven2/aspectj/aspectjrt/1.5.3/aspectjrt-1.5.3.pom
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-classworlds/1.2-alpha-10/plexus-classworlds-1.2-alpha-10.pom
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.2/plexus-archiver-1.2.pom
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0.1/plexus-io-1.0.1.pom
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.2/plexus-archiver-1.2.jar
Downloading:
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0.1/plexus-io-1.0.1.jar
[INFO] [jarjar:jarjar {execution: default}]
[INFO] Processing:
/srv/gump/public/workspace/apache-commons/digester/core/target/classes
[INFO] Building zip:
/srv/gump/public/workspace/apache-commons/digester/core/target/jarjar/uber-classes
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] JarJar'ing to:
/srv/gump/public/workspace/apache-commons/digester/core/target/classes-shaded
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/srv/gump/public/workspace/apache-commons/digester/core/target/commons-digester3-3.3-SNAPSHOT.jar
[INFO] [antrun:run {execution: uberjar.resources}]
[INFO] Executing tasks
main:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured:
/srv/gump/public/workspace/apache-commons/digester/core/src/main/assembly does
not exist.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 14 seconds
[INFO] Finished at: Sun Feb 12 02:13:53 UTC 2012
[INFO] Final Memory: 59M/141M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/apache-commons/commo
[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed
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 issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 23 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.028 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.031 ms Process completed in 2005 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2004 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8030 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.9 sec <<< FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Sun Feb 12 02:19:26 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1012022012, vmgump.apache.org:vmgump:1012022012 Gump E-mail Identifier (unique within run) #20. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Make everything "Serializable" ?
No. I never use Java serialization if I can help it. On Sat, Feb 11, 2012 at 8:57 AM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > On Sat, Feb 11, 2012 at 08:31:53AM -0800, Ted Dunning wrote: > > Interesting that you say that because long-term storage of data and > > communication between distributed components are exactly what I use > > serialization for. Note that communication between components almost > > automatically implies version mismatch in lots of production systems > > exactly because you can't update all components simultaneously. > > > > Systems like Avro, Thrift, Protobufs and Kryo all exist precisely because > > native serialization is so terribly broken. > > Do you mean that you use a broken system for long-term storage? >
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
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 issue affects 1 projects, and has been outstanding for 397 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.139 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Sun Feb 12 05:36:53 UTC 2012 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.
