Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/
Jörg, what about all older living projects which used to have own groups even, like commons-lang:commons-lang? Could you point me to this boilerplate stuff you think off? Maybe we can improve this. I have no problem with moving the packages back, but I personally think this would á la long end up in confusing end users. LieGrue, strub - Original Message - > From: Jörg Schaible > To: dev@commons.apache.org > Cc: > Sent: Friday, December 21, 2012 1:23 AM > Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ > ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ > modules/privilizer/api/ > modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ > modules/privi... > > Matt Benson wrote: > >> Mark, >> Thanks for driving this forward--as I mentioned to you privately, > I'll >> be >> mostly out of pocket through the new year. The groupId may warrant >> discussion; most Commons components are being targeted to >> org.apache.commons, though I think I understand what you're driving at >> here: [weaver] may have some unlimited number of sub(-sub*)-modules which >> may warrant oac.weaver as a groupId. > > Actually I think this is a bad idea. We manage all of our components as one > large group and should not break consistency here. I don't want to know what > > effect this also has on some of our boiler plates we use for the build. > > - Jörg > > > - > 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][RC5] Release Commons Math 3.1
On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > Hi. > > Please have a look at the next candidate (RC5), and vote for the release > of Commons Math 3.1. > > -- > Tag: > https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/ > > Site: > http://people.apache.org/builds/commons/math/3.1/RC5/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/ > > [ ] +1 Release it. > [ ] +0 Go ahead; I don't care. > [ ] -0 There are a few minor glitches: ... > [ ] -1 No, do not release it because ... > > This vote will close in 72 hours. > -- > Hi, this is not yet my vote, just a request for clarification. I checked again the Clirr errors, and there are still the two related to the probability method in LogNormal and NormalDistribution. In 3.0, there was a method with only 1 parameter, which always returned 0. Now there is a probability method with two parameters, which is defined in the implemented interface AbstractRealDistribution. You mentioned that this is a false positive, but I doubt this. Maybe the probability method was never used, but then it should at least be mentioned in the release notes. Sorry to be pedantic about this. Thomas
Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/
Hi Mark, Mark Struberg wrote: > Jörg, what about all older living projects which used to have own groups > even, like commons-lang:commons-lang? groupIds with pattern commons-XXX are legacy and we keep them only because the relocation stuff of Maven does not really work well and we don't want to harass our users as long as any newer release is binary compatible. However, for new components or as soon as a new binary incompatible version of an old one is to be released, we change the groupId always to org.commons.apache and this had been the case for *all* components until now. > Could you point me to this boilerplate stuff you think off? Maybe we can > improve this. IIRC we derive the value for the groupId from our parent pom at various places and we had also manual tasks for infra for all our components with a groupId of commons-xxx and I am not sure if this applies to all groupIds that are unequal to org.apache.commons. > I have no problem with moving the packages back, but I personally think > this would á la long end up in confusing end users. As said, we have with vfs2 and jci already other commons components that make a precedence for multiple artifacts of one component. We share org.apache.commons as common groupId and therefore I am against a silent change of naming policy here. Note, that I did not veto the commit, because I want to hear other opinions, but without a consensus among us committers, I'd veto any such release. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/
No worries Jörg, I was just not aware of those additional steps/scripts. From a pure maven perspective I would prefer separate groupIds but I get your arguments regarding the other tooling. Thanks for pointing me to this background! I will change the groupIds back to o.a.c. LieGrue, strub - Original Message - > From: Jörg Schaible > To: dev@commons.apache.org > Cc: > Sent: Friday, December 21, 2012 10:31 AM > Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ > ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ > modules/privilizer/api/ > modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ > modules/privi... > > Hi Mark, > > Mark Struberg wrote: > >> Jörg, what about all older living projects which used to have own groups >> even, like commons-lang:commons-lang? > > groupIds with pattern commons-XXX are legacy and we keep them only because > the relocation stuff of Maven does not really work well and we don't want to > > harass our users as long as any newer release is binary compatible. However, > for new components or as soon as a new binary incompatible version of an old > one is to be released, we change the groupId always to org.commons.apache > and this had been the case for *all* components until now. > >> Could you point me to this boilerplate stuff you think off? Maybe we can >> improve this. > > IIRC we derive the value for the groupId from our parent pom at various > places and we had also manual tasks for infra for all our components with a > groupId of commons-xxx and I am not sure if this applies to all groupIds > that are unequal to org.apache.commons. > >> I have no problem with moving the packages back, but I personally think >> this would á la long end up in confusing end users. > > As said, we have with vfs2 and jci already other commons components that > make a precedence for multiple artifacts of one component. We share > org.apache.commons as common groupId and therefore I am against a silent > change of naming policy here. Note, that I did not veto the commit, because > I want to hear other opinions, but without a consensus among us committers, > I'd veto any such release. > > Cheers, > Jörg > > > - > 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: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/
committed in r1424835. Please note that weaver alone has 11 modules so far. And it's likely to become more... LieGrue, strub - Original Message - > From: Mark Struberg > To: Commons Developers List > Cc: > Sent: Friday, December 21, 2012 10:43 AM > Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ > ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ > modules/privilizer/api/ > modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ > modules/privi... > > No worries Jörg, I was just not aware of those additional steps/scripts. > From a pure maven perspective I would prefer separate groupIds but I get your > arguments regarding the other tooling. > > Thanks for pointing me to this background! > > I will change the groupIds back to o.a.c. > > LieGrue, > strub > > > > - Original Message - >> From: Jörg Schaible >> To: dev@commons.apache.org >> Cc: >> Sent: Friday, December 21, 2012 10:31 AM >> Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: > ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ > modules/privilizer/ > modules/privilizer/api/ > modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ > modules/privi... >> >> Hi Mark, >> >> Mark Struberg wrote: >> >>> Jörg, what about all older living projects which used to have own > groups >>> even, like commons-lang:commons-lang? >> >> groupIds with pattern commons-XXX are legacy and we keep them only because >> the relocation stuff of Maven does not really work well and we don't > want to >> >> harass our users as long as any newer release is binary compatible. > However, >> for new components or as soon as a new binary incompatible version of an > old >> one is to be released, we change the groupId always to org.commons.apache >> and this had been the case for *all* components until now. >> >>> Could you point me to this boilerplate stuff you think off? Maybe we > can >>> improve this. >> >> IIRC we derive the value for the groupId from our parent pom at various >> places and we had also manual tasks for infra for all our components with a > >> groupId of commons-xxx and I am not sure if this applies to all groupIds >> that are unequal to org.apache.commons. >> >>> I have no problem with moving the packages back, but I personally > think >>> this would á la long end up in confusing end users. >> >> As said, we have with vfs2 and jci already other commons components that >> make a precedence for multiple artifacts of one component. We share >> org.apache.commons as common groupId and therefore I am against a silent >> change of naming policy here. Note, that I did not veto the commit, because > >> I want to hear other opinions, but without a consensus among us committers, > >> I'd veto any such release. >> >> Cheers, >> Jörg >> >> >> - >> 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][RC5] Release Commons Math 3.1
On Dec 21, 2012, at 4:18, Thomas Neidhart wrote: > On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > >> Hi. >> >> Please have a look at the next candidate (RC5), and vote for the release >> of Commons Math 3.1. >> >> -- >> Tag: >> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/ >> >> Site: >> http://people.apache.org/builds/commons/math/3.1/RC5/ >> >> Binaries: >> >> https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/ >> >> [ ] +1 Release it. >> [ ] +0 Go ahead; I don't care. >> [ ] -0 There are a few minor glitches: ... >> [ ] -1 No, do not release it because ... >> >> This vote will close in 72 hours. >> -- > > Hi, > > this is not yet my vote, just a request for clarification. > > I checked again the Clirr errors, and there are still the two related to > the probability method in LogNormal and NormalDistribution. > > In 3.0, there was a method with only 1 parameter, which always returned 0. > Now there is a probability method with two parameters, which is defined in > the implemented interface AbstractRealDistribution. > > You mentioned that this is a false positive, but I doubt this. Maybe the > probability method was never used, but then it should at least be mentioned > in the release notes. > > Sorry to be pedantic about this. Clirr lists 7 errors, so strictly speaking it does not looks like 3.1 is binary compatible with 3.0. I see these options: 1) document 3.1 as not BC. This is not what we usually do in Commons. 2) fix the clirr errors in the code. This is the safe option. 3) make this a 4.0 releases and change the packages and maven coordinates. This seems like a high price and likely not what the [math] community intends for a real 4.0. Gary > > Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/
Hi Mark, Mark Struberg wrote: > committed in r1424835. > > Please note that weaver alone has 11 modules so far. And it's likely to > become more... commons-jci has 9 so far. As said, I simply want to have a community decision for such a change in the naming conventions. Tooling can be adjusted, if majority of committers agree on individual groupIds for components with the consequence that vfs2 and jci should be aligned with the next major incompatible version. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC5] Release Commons Math 3.1
On Fri, Dec 21, 2012 at 10:17:59AM +0100, Thomas Neidhart wrote: > On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > > > Hi. > > > > Please have a look at the next candidate (RC5), and vote for the release > > of Commons Math 3.1. > > > > -- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/ > > > > Site: > > http://people.apache.org/builds/commons/math/3.1/RC5/ > > > > Binaries: > > > > https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/ > > > > [ ] +1 Release it. > > [ ] +0 Go ahead; I don't care. > > [ ] -0 There are a few minor glitches: ... > > [ ] -1 No, do not release it because ... > > > > This vote will close in 72 hours. > > -- > > > > Hi, > > this is not yet my vote, just a request for clarification. > > I checked again the Clirr errors, and there are still the two related to > the probability method in LogNormal and NormalDistribution. > > In 3.0, there was a method with only 1 parameter, which always returned 0. > Now there is a probability method with two parameters, which is defined in > the implemented interface AbstractRealDistribution. And... there is a method with one parameter that always return zero in the _parent_ class. Any code the calls the one-arg "probablility" method will get the same result (i.e zero) as before. > > You mentioned that this is a false positive, but I doubt this. Why? > Maybe the > probability method was never used, It was not used in CM, but that would not be a good excuse I guess. ;-) > but then it should at least be mentioned > in the release notes. As I indicated previously, if this is a false positive, there is doubtful usefulness to explaining a bug in a reporting tool. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC5] Release Commons Math 3.1
On Fri, Dec 21, 2012 at 1:05 PM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > On Fri, Dec 21, 2012 at 10:17:59AM +0100, Thomas Neidhart wrote: > > On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski < > > gil...@harfang.homelinux.org> wrote: > > > > > Hi. > > > > > > Please have a look at the next candidate (RC5), and vote for the > release > > > of Commons Math 3.1. > > > > > > -- > > > Tag: > > > > https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/ > > > > > > Site: > > > http://people.apache.org/builds/commons/math/3.1/RC5/ > > > > > > Binaries: > > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/ > > > > > > [ ] +1 Release it. > > > [ ] +0 Go ahead; I don't care. > > > [ ] -0 There are a few minor glitches: ... > > > [ ] -1 No, do not release it because ... > > > > > > This vote will close in 72 hours. > > > -- > > > > > > > Hi, > > > > this is not yet my vote, just a request for clarification. > > > > I checked again the Clirr errors, and there are still the two related to > > the probability method in LogNormal and NormalDistribution. > > > > In 3.0, there was a method with only 1 parameter, which always returned > 0. > > Now there is a probability method with two parameters, which is defined > in > > the implemented interface AbstractRealDistribution. > > And... there is a method with one parameter that always return zero in the > _parent_ class. Any code the calls the one-arg "probablility" method will > get the same result (i.e zero) as before. > > > > > You mentioned that this is a false positive, but I doubt this. > > Why? > > > Maybe the > > probability method was never used, > > It was not used in CM, but that would not be a good excuse I guess. ;-) > > > but then it should at least be mentioned > > in the release notes. > > As I indicated previously, if this is a false positive, there is doubtful > usefulness to explaining a bug in a reporting tool. > Hi Gilles, you are right, sorry I missed the inherited method. So then +1 from my side too. Thomas
Re: [VOTE][RC5] Release Commons Math 3.1
On Fri, Dec 21, 2012 at 06:40:36AM -0500, Gary Gregory wrote:
> On Dec 21, 2012, at 4:18, Thomas Neidhart wrote:
>
> > On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski <
> > gil...@harfang.homelinux.org> wrote:
> >
> >> Hi.
> >>
> >> Please have a look at the next candidate (RC5), and vote for the release
> >> of Commons Math 3.1.
> >>
> >> --
> >> Tag:
> >> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/
> >>
> >> Site:
> >> http://people.apache.org/builds/commons/math/3.1/RC5/
> >>
> >> Binaries:
> >>
> >> https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/
> >>
> >> [ ] +1 Release it.
> >> [ ] +0 Go ahead; I don't care.
> >> [ ] -0 There are a few minor glitches: ...
> >> [ ] -1 No, do not release it because ...
> >>
> >> This vote will close in 72 hours.
> >> --
> >
> > Hi,
> >
> > this is not yet my vote, just a request for clarification.
> >
> > I checked again the Clirr errors, and there are still the two related to
> > the probability method in LogNormal and NormalDistribution.
> >
> > In 3.0, there was a method with only 1 parameter, which always returned 0.
> > Now there is a probability method with two parameters, which is defined in
> > the implemented interface AbstractRealDistribution.
> >
> > You mentioned that this is a false positive, but I doubt this. Maybe the
> > probability method was never used, but then it should at least be mentioned
> > in the release notes.
> >
> > Sorry to be pedantic about this.
>
> Clirr lists 7 errors, so strictly speaking it does not looks like 3.1
> is binary compatible with 3.0. I see these options:
At the time of deleting the "enum" fields ("ALPHA", "BETA", etc), we got a
green light, on the basis that those fields were only meant for CM's
internal use.
You are certainly right that someone who actually use those in his
application will get into trouble; but then we knew that when we discussed
the removal. We agreed that this situation was clear and not to be taken
into account.
For the reports on the method signature change, I've answered to Thomas's
post.
Could please someone point to a source other than Clirr if it is not
satisfactory?
Thanks,
Gilles
>
> 1) document 3.1 as not BC. This is not what we usually do in Commons.
> 2) fix the clirr errors in the code. This is the safe option.
> 3) make this a 4.0 releases and change the packages and maven
> coordinates. This seems like a high price and likely not what the
> [math] community intends for a real 4.0.
>
> Gary
>
>
> >
> > Thomas
>
> -
> 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: svn commit: r1424678 - /commons/trunks-proper/pom.xml
Le 20/12/2012 21:34, ol...@apache.org a écrit : > Author: olamy > Date: Thu Dec 20 20:34:22 2012 > New Revision: 1424678 > > URL: http://svn.apache.org/viewvc?rev=1424678&view=rev > Log: > math in aggregator build -> will be available in analysis.a.o > > Modified: > commons/trunks-proper/pom.xml > > Modified: commons/trunks-proper/pom.xml > URL: > http://svn.apache.org/viewvc/commons/trunks-proper/pom.xml?rev=1424678&r1=1424677&r2=1424678&view=diff > == > --- commons/trunks-proper/pom.xml (original) > +++ commons/trunks-proper/pom.xml Thu Dec 20 20:34:22 2012 > @@ -38,6 +38,7 @@ > cli > ognl > exec > +math > > > > > > Thanks Olivier. Luc - 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 32 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.022 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.026 ms Process completed in 2003 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 2003 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 8041 millis; above is its output Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg ms): 1004 Tests run: 41, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.72 sec <<< FAILURE! testExec_60(org.apache.commons.exec.DefaultExecutorTest) Time elapsed: 6.038 sec <<< FAILURE! junit.framework.AssertionFailedError: Not a single process was killed by the watch dog at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.exec.DefaultExecutorTest.testExec_60(DefaultExecutorTest.java:1129) Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest): Not a single process was killed by the watch dog Tests run: 96, 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 30 seconds [INFO] Finished at: Fri Dec 21 14:24:18 UTC 2012 [INFO] Final Memory: 46M/111M [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 06001221122012, vmgump.apache.org:vmgump:06001221122012 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsu
Re: [Math] Request for future releases: kill Cobertura
On 12/20/12 1:25 PM, Olivier Lamy wrote: > 2012/12/20 Luc Maisonobe : >> Le 20/12/2012 18:05, Benedikt Ritter a écrit : >>> 2012/12/20 luc >>> Le 2012-12-20 15:01, Phil Steitz a écrit : On 12/19/12 6:19 PM, Gilles Sadowski wrote: >> Hello. >> Hi all, >> The situation with "Cobertura" is fairly annoying, perhaps particularly >> so >> for Commons Math because of the size of the code base (and thus the >> fairly >> large number of unit tests). >> >> As it just happened, a few minor problems have now delayed the release by >> several days because I have to wait about 4 hours for the site generation >> to complete (on a _fast_ machine). >> Hence the request to remove Cobertura from the "site" target, or at least >> from the "site:stage-deploy" step, so that a new vote can take place as >> soon >> as a problem is fixed. >> [I would even argue that it is not that useful to include Cobertura in >> the >> release process because the amount of code coverage is not acted upon >> (i.e. >> low coverage would not block a release IIUC).] >> >> Do you agree? >> > +1 > >> If so, can we change that for Commons Math only, or should this be done >> at >> the "parent" level? Is is just a matter of adding >> true >> in a new profile? >> > This is an argument that we have from time to time. IMO the parent > should contain a minimal set of plugins and component POMs should > explicitly include the ones they want. I would be +1 for dropping > Coberta from the parent pom. > I will play devils advocate. Cobertura is really useful and provides useful information. It also clearly help popularizing [math] as we can prove it is a well tested component. So I don't agree removing it totally. However, I agree it has become really annoying mainly due to its very poor performances with respect to Bobyqa tests. It really takes hours to perform all site generation. Gilles spoke about 4 hours on a fast machine, but my home computer is not fast and it takes much longer to me. When I want to do a full generation, I let it run overnight. So if another mean to have the same information is available (or to make cobertura run faster, especially for the bobyqa test), then I would be glad to drop cobertura. If there are no other means, I would not be glad. I would prefer than the output from the test coverage would end up in the public site. Even if only the current trunk is covered, that would be sufficient for my needs, so if some existing continuous integration system can be set up, I'm fine with that. Note that we really need to get information down to line of code level, as it is the only way we can extend tests. The cobertura report is really nice for that as it directly provides colored versions of the source code which are really easy to use for the developer. >>> Hi Luc, >> Hi Benedikt, >> >>> have a look at the test installation Oliver has set up: >>> https://analysis.apache.org/components/index/121254, for example have a >>> look at the org.apache.commons.lang3.builder package: >>> https://analysis.apache.org/components/index/121815 >>> If you click on one of the magnifying glasses on the right side, you get a >>> detailed view of a particular class. Click on the Coverage tab in the top >>> right side and you will have the coverage displayed like in Cobertura. >> Thank you very much for the link. >> This report is really useful, and provides even more hindsight thant the >> cobertura one. >> >> So a big +1 to heve it enabled for [math] replacing cobertura! > Done check here https://analysis.apache.org/dashboard/index/122571 > > De rien :-) > > Note: to add more projects just a in this pom > http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml > > Daily in case of any scm changes in path > http://svn.apache.org/repos/asf/commons/trunks-proper/ report are > rebuild. > > Note: Sonar use jacoco and not cobertura. > Some details on differences here: > http://www.dzone.com/links/r/code_coverage_tools_jacoco_cobertura_emma_compari.html Thanks! Now can we either dump coberta from commons parent or can someone indicate a way that actually works to turn it off? I can't get any of the tricks mentioned so far to work. I get strange errors when I try to either configure the skip parameter for it in the component pom or use the command line. Phil > > >> Luc >> >> >>> Benedikt >>> >>> >>> best regards, Luc > Phil > >> >> Regards, >> Gilles >> >> >> --**--** >> - >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org >> For additional commands, e-mail: dev-h...@commons.a
Re: [Math] Request for future releases: kill Cobertura
-Dcobertura.skip=true ? or in pom.properties true 2012/12/21 Phil Steitz : > On 12/20/12 1:25 PM, Olivier Lamy wrote: >> 2012/12/20 Luc Maisonobe : >>> Le 20/12/2012 18:05, Benedikt Ritter a écrit : 2012/12/20 luc > Le 2012-12-20 15:01, Phil Steitz a écrit : > > On 12/19/12 6:19 PM, Gilles Sadowski wrote: >>> Hello. >>> > Hi all, > > > >>> The situation with "Cobertura" is fairly annoying, perhaps particularly >>> so >>> for Commons Math because of the size of the code base (and thus the >>> fairly >>> large number of unit tests). >>> >>> As it just happened, a few minor problems have now delayed the release >>> by >>> several days because I have to wait about 4 hours for the site >>> generation >>> to complete (on a _fast_ machine). >>> Hence the request to remove Cobertura from the "site" target, or at >>> least >>> from the "site:stage-deploy" step, so that a new vote can take place as >>> soon >>> as a problem is fixed. >>> [I would even argue that it is not that useful to include Cobertura in >>> the >>> release process because the amount of code coverage is not acted upon >>> (i.e. >>> low coverage would not block a release IIUC).] >>> >>> Do you agree? >>> >> +1 >> >>> If so, can we change that for Commons Math only, or should this be done >>> at >>> the "parent" level? Is is just a matter of adding >>> true >>> in a new profile? >>> >> This is an argument that we have from time to time. IMO the parent >> should contain a minimal set of plugins and component POMs should >> explicitly include the ones they want. I would be +1 for dropping >> Coberta from the parent pom. >> > I will play devils advocate. Cobertura is really useful and provides > useful > information. It also clearly help popularizing [math] as we can prove it > is > a well tested component. So I don't agree removing it totally. > > However, I agree it has become really annoying mainly due to its very poor > performances with respect to Bobyqa tests. It really takes hours to > perform > all site generation. Gilles spoke about 4 hours on a fast machine, but my > home computer is not fast and it takes much longer to me. When I want to > do > a full generation, I let it run overnight. > > So if another mean to have the same information is available (or to make > cobertura run faster, especially for the bobyqa test), then I would > be glad to drop cobertura. If there are no other means, I would not be > glad. > > I would prefer than the output from the test coverage would end up in the > public > site. Even if only the current trunk is covered, that would be sufficient > for > my needs, so if some existing continuous integration system can be set up, > I'm > fine with that. Note that we really need to get information down to line > of code > level, as it is the only way we can extend tests. The cobertura report is > really > nice for that as it directly provides colored versions of the source code > which > are really easy to use for the developer. > Hi Luc, >>> Hi Benedikt, >>> have a look at the test installation Oliver has set up: https://analysis.apache.org/components/index/121254, for example have a look at the org.apache.commons.lang3.builder package: https://analysis.apache.org/components/index/121815 If you click on one of the magnifying glasses on the right side, you get a detailed view of a particular class. Click on the Coverage tab in the top right side and you will have the coverage displayed like in Cobertura. >>> Thank you very much for the link. >>> This report is really useful, and provides even more hindsight thant the >>> cobertura one. >>> >>> So a big +1 to heve it enabled for [math] replacing cobertura! >> Done check here https://analysis.apache.org/dashboard/index/122571 >> >> De rien :-) >> >> Note: to add more projects just a in this pom >> http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml >> >> Daily in case of any scm changes in path >> http://svn.apache.org/repos/asf/commons/trunks-proper/ report are >> rebuild. >> >> Note: Sonar use jacoco and not cobertura. >> Some details on differences here: >> http://www.dzone.com/links/r/code_coverage_tools_jacoco_cobertura_emma_compari.html > > Thanks! > > Now can we either dump coberta from commons parent or can someone > indicate a way that actually works to turn it off? I can't get any > of the tricks mentioned so far to work. I get strange errors when I > try to either configure the skip parameter for it in the component > pom or use the command line. > > Phil >> >> >>> Luc >>> >>> Benedikt > best regards, > Luc > > > >> Phil >>
Re: [Math] Request for future releases: kill Cobertura
Hi, 2012/12/21 Olivier Lamy > -Dcobertura.skip=true ? > or in pom.properties > true > > I agree with Phil, both options lead to strange error messages (see my post above). Should it be considered as a bug of the cobertura plugin? Sébastien 2012/12/21 Phil Steitz : > > On 12/20/12 1:25 PM, Olivier Lamy wrote: > >> 2012/12/20 Luc Maisonobe : > >>> Le 20/12/2012 18:05, Benedikt Ritter a écrit : > 2012/12/20 luc > > > Le 2012-12-20 15:01, Phil Steitz a écrit : > > > > On 12/19/12 6:19 PM, Gilles Sadowski wrote: > >>> Hello. > >>> > > Hi all, > > > > > > > >>> The situation with "Cobertura" is fairly annoying, perhaps > particularly > >>> so > >>> for Commons Math because of the size of the code base (and thus the > >>> fairly > >>> large number of unit tests). > >>> > >>> As it just happened, a few minor problems have now delayed the > release by > >>> several days because I have to wait about 4 hours for the site > generation > >>> to complete (on a _fast_ machine). > >>> Hence the request to remove Cobertura from the "site" target, or > at least > >>> from the "site:stage-deploy" step, so that a new vote can take > place as > >>> soon > >>> as a problem is fixed. > >>> [I would even argue that it is not that useful to include > Cobertura in > >>> the > >>> release process because the amount of code coverage is not acted > upon > >>> (i.e. > >>> low coverage would not block a release IIUC).] > >>> > >>> Do you agree? > >>> > >> +1 > >> > >>> If so, can we change that for Commons Math only, or should this be > done > >>> at > >>> the "parent" level? Is is just a matter of adding > >>> true > >>> in a new profile? > >>> > >> This is an argument that we have from time to time. IMO the parent > >> should contain a minimal set of plugins and component POMs should > >> explicitly include the ones they want. I would be +1 for dropping > >> Coberta from the parent pom. > >> > > I will play devils advocate. Cobertura is really useful and provides > useful > > information. It also clearly help popularizing [math] as we can > prove it is > > a well tested component. So I don't agree removing it totally. > > > > However, I agree it has become really annoying mainly due to its > very poor > > performances with respect to Bobyqa tests. It really takes hours to > perform > > all site generation. Gilles spoke about 4 hours on a fast machine, > but my > > home computer is not fast and it takes much longer to me. When I > want to do > > a full generation, I let it run overnight. > > > > So if another mean to have the same information is available (or to > make > > cobertura run faster, especially for the bobyqa test), then I would > > be glad to drop cobertura. If there are no other means, I would not > be > > glad. > > > > I would prefer than the output from the test coverage would end up > in the > > public > > site. Even if only the current trunk is covered, that would be > sufficient > > for > > my needs, so if some existing continuous integration system can be > set up, > > I'm > > fine with that. Note that we really need to get information down to > line > > of code > > level, as it is the only way we can extend tests. The cobertura > report is > > really > > nice for that as it directly provides colored versions of the source > code > > which > > are really easy to use for the developer. > > > Hi Luc, > >>> Hi Benedikt, > >>> > have a look at the test installation Oliver has set up: > https://analysis.apache.org/components/index/121254, for example > have a > look at the org.apache.commons.lang3.builder package: > https://analysis.apache.org/components/index/121815 > If you click on one of the magnifying glasses on the right side, you > get a > detailed view of a particular class. Click on the Coverage tab in the > top > right side and you will have the coverage displayed like in Cobertura. > >>> Thank you very much for the link. > >>> This report is really useful, and provides even more hindsight thant > the > >>> cobertura one. > >>> > >>> So a big +1 to heve it enabled for [math] replacing cobertura! > >> Done check here https://analysis.apache.org/dashboard/index/122571 > >> > >> De rien :-) > >> > >> Note: to add more projects just a in this pom > >> http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml > >> > >> Daily in case of any scm changes in path > >> http://svn.apache.org/repos/asf/commons/trunks-proper/ report are > >> rebuild. > >> > >> Note: Sonar use jacoco and not cobertura. > >> Some details on differences here: > >> > http://www.dzone.com/links/r/code_coverage_tools_jacoco_cobertura_emma_compari.html > > > > Thanks! > > > > Now can we either dump
Re: [VOTE][RC5] Release Commons Math 3.1
On Fri, Dec 21, 2012 at 01:13:48PM +0100, Gilles Sadowski wrote:
> On Fri, Dec 21, 2012 at 06:40:36AM -0500, Gary Gregory wrote:
> > On Dec 21, 2012, at 4:18, Thomas Neidhart wrote:
> >
> > > On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski <
> > > gil...@harfang.homelinux.org> wrote:
> > >
> > >> Hi.
> > >>
> > >> Please have a look at the next candidate (RC5), and vote for the release
> > >> of Commons Math 3.1.
> > >>
> > >> --
> > >> Tag:
> > >> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/
> > >>
> > >> Site:
> > >> http://people.apache.org/builds/commons/math/3.1/RC5/
> > >>
> > >> Binaries:
> > >>
> > >> https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/
> > >>
> > >> [ ] +1 Release it.
> > >> [ ] +0 Go ahead; I don't care.
> > >> [ ] -0 There are a few minor glitches: ...
> > >> [ ] -1 No, do not release it because ...
> > >>
> > >> This vote will close in 72 hours.
> > >> --
> > >
> > > Hi,
> > >
> > > this is not yet my vote, just a request for clarification.
> > >
> > > I checked again the Clirr errors, and there are still the two related to
> > > the probability method in LogNormal and NormalDistribution.
> > >
> > > In 3.0, there was a method with only 1 parameter, which always returned 0.
> > > Now there is a probability method with two parameters, which is defined in
> > > the implemented interface AbstractRealDistribution.
> > >
> > > You mentioned that this is a false positive, but I doubt this. Maybe the
> > > probability method was never used, but then it should at least be
> > > mentioned
> > > in the release notes.
> > >
> > > Sorry to be pedantic about this.
> >
> > Clirr lists 7 errors, so strictly speaking it does not looks like 3.1
> > is binary compatible with 3.0. I see these options:
>
> At the time of deleting the "enum" fields ("ALPHA", "BETA", etc), we got a
> green light, on the basis that those fields were only meant for CM's
> internal use.
>
> You are certainly right that someone who actually use those in his
> application will get into trouble; but then we knew that when we discussed
> the removal. We agreed that this situation was clear and not to be taken
> into account.
>
> For the reports on the method signature change, I've answered to Thomas's
> post.
> Could please someone point to a source other than Clirr if it is not
> satisfactory?
>
> >
> > 1) document 3.1 as not BC. This is not what we usually do in Commons.
> > 2) fix the clirr errors in the code. This is the safe option.
> > 3) make this a 4.0 releases and change the packages and maven
> > coordinates. This seems like a high price and likely not what the
> > [math] community intends for a real 4.0.
> >
So? In the unlikely event that someone complains about missing fields from
the "LocalizedFormats" enum, do we assume that binary compatibility does not
cover such things as using CM's "internal" classes (even if we cannot
enforce this restriction in Java)?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[functor] Using [fucntor] functional interfaces with Java 8 lambdas
Hi all,
Just wanted to let you guys know that I am successfully compiling and executing
code using [functor] and Java 8. And am also using [functor] functional
interfaces with lambdas.
So instead of writing:
UnaryPredicate isEven = new UnaryPredicate() {
public boolean test(Integer obj) {
return obj % 2 == 0;
}
};
One can simply write:
UnaryPredicate isEven = (Integer obj) -> { return obj % 2 == 0; };
FWIW, Google Guava's Predicate [1] is not a functional interface, so it cannot
be used with lambdas, as in the example above.
I'll continue to experiment with [functor] and Java 8. There are only two open
issues in Jira, one regarding generators (there's a branch with a proposal
implementation) and another one about the equals() method in the [functor] API.
I wrote a short blog post [2] about how I'm running Java 8 in Eclipse Juno, in
case anyone is interested in trying it too. The code is hosted at GitHub [3].
Cheers,
[1] http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/Predicate.java
[2] http://www.kinoshita.eti.br/2012/12/21/using-apache-commons-functor-functional-interfaces-with-java-8-lambdas/
[3] https://github.com/kinow/try-lambdas
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [functor] Using [fucntor] functional interfaces with Java 8 lambdas
Very exciting! Thanks, Bruno!
Matt
On Fri, Dec 21, 2012 at 1:22 PM, Bruno P. Kinoshita <
brunodepau...@yahoo.com.br> wrote:
> Hi all,
>
> Just wanted to let you guys know that I am successfully compiling and
> executing code using [functor] and Java 8. And am also using [functor]
> functional interfaces with lambdas.
>
> So instead of writing:
>
>
> UnaryPredicate isEven = new UnaryPredicate() {
> public boolean test(Integer obj) {
> return obj % 2 == 0;
> }
> };
>
> One can simply write:
>
> UnaryPredicate isEven = (Integer obj) -> { return obj % 2 == 0; };
>
> FWIW, Google Guava's Predicate [1] is not a functional interface, so it
> cannot be used with lambdas, as in the example above.
>
> I'll continue to experiment with [functor] and Java 8. There are only two
> open issues in Jira, one regarding generators (there's a branch with a
> proposal implementation) and another one about the equals() method in the
> [functor] API.
>
> I wrote a short blog post [2] about how I'm running Java 8 in Eclipse
> Juno, in case anyone is interested in trying it too. The code is hosted at
> GitHub [3].
>
> Cheers,
>
> [1]
> http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/Predicate.java
> [2]
> http://www.kinoshita.eti.br/2012/12/21/using-apache-commons-functor-functional-interfaces-with-java-8-lambdas/
> [3] https://github.com/kinow/try-lambdas
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [Math] Request for future releases: kill Cobertura
On 12/21/12 10:53 AM, Sébastien Brisard wrote:
> Hi,
>
>
> 2012/12/21 Olivier Lamy
>
>> -Dcobertura.skip=true ?
>> or in pom.properties
>> true
>>
>> I agree with Phil, both options lead to strange error messages (see my
> post above). Should it be considered as a bug of the cobertura plugin?
Looks like the plugin is definitely broken. I get this with the
command-line option above:
*[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Skipping cobertura execution
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 28 resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/Users/psteitz/newMath/trunk/target/surefire-reports
---
T E S T S
---
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/math3/exception/DimensionMismatchException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
It is trying to needlessly execute the tests the second time as if
it were generating the cobertura report.
I really wish we could just drop this and the other reporting
plugins from the parent and have components add the ones they want.
In our [math] pom, we add configs for several of them anyway.
Phil
*
>
> Sébastien
>
> 2012/12/21 Phil Steitz :
>
>>> On 12/20/12 1:25 PM, Olivier Lamy wrote:
2012/12/20 Luc Maisonobe :
> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>> 2012/12/20 luc
>>
>>> Le 2012-12-20 15:01, Phil Steitz a écrit :
>>>
>>> On 12/19/12 6:19 PM, Gilles Sadowski wrote:
> Hello.
>
>>> Hi all,
>>>
>>>
>>>
> The situation with "Cobertura" is fairly annoying, perhaps
>> particularly
> so
> for Commons Math because of the size of the code base (and thus the
> fairly
> large number of unit tests).
>
> As it just happened, a few minor problems have now delayed the
>> release by
> several days because I have to wait about 4 hours for the site
>> generation
> to complete (on a _fast_ machine).
> Hence the request to remove Cobertura from the "site" target, or
>> at least
> from the "site:stage-deploy" step, so that a new vote can take
>> place as
> soon
> as a problem is fixed.
> [I would even argue that it is not that useful to include
>> Cobertura in
> the
> release process because the amount of code coverage is not acted
>> upon
> (i.e.
> low coverage would not block a release IIUC).]
>
> Do you agree?
>
+1
> If so, can we change that for Commons Math only, or should this be
>> done
> at
> the "parent" level? Is is just a matter of adding
> true
> in a new profile?
>
This is an argument that we have from time to time. IMO the parent
should contain a minimal set of plugins and component POMs should
explicitly include the ones they want. I would be +1 for dropping
Coberta from the parent pom.
>>> I will play devils advocate. Cobertura is really useful and provides
>> useful
>>> information. It also clearly help popularizing [math] as we can
>> prove it is
>>> a well tested component. So I don't agree removing it totally.
>>>
>>> However, I agree it has become really annoying mainly due to its
>> very poor
>>> performances with respect to Bobyqa tests. It really takes hours to
>> perform
>>> all site generat
Re: [VOTE][RC5] Release Commons Math 3.1
2012/12/20 Gilles Sadowski
> Hi.
>
> Please have a look at the next candidate (RC5), and vote for the release
> of Commons Math 3.1.
>
> --
> Tag:
> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/
>
> Site:
> http://people.apache.org/builds/commons/math/3.1/RC5/
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/
>
> [X] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
>
Thanks Gilles. I agree about the "enum" fields ("ALPHA", "BETA", etc).
These were widely discussed on the ML before we proceeded.
Sébastien
Re: [VOTE][RC5] Release Commons Math 3.1
On 12/20/12 2:26 AM, Gilles Sadowski wrote: > Hi. > > Please have a look at the next candidate (RC5), and vote for the release > of Commons Math 3.1. > > -- > Tag: > https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/ > > Site: > http://people.apache.org/builds/commons/math/3.1/RC5/ > > Binaries: > > https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/ > > [x] +1 Release it. > [ ] +0 Go ahead; I don't care. > [ ] -0 There are a few minor glitches: ... > [ ] -1 No, do not release it because ... > > This vote will close in 72 hours. Thanks, Gilles! Phil > -- > > > Thanks, > 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
Re: [VOTE][RC5] Release Commons Math 3.1
On 12/21/12 4:09 AM, Thomas Neidhart wrote: > On Fri, Dec 21, 2012 at 1:05 PM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > >> On Fri, Dec 21, 2012 at 10:17:59AM +0100, Thomas Neidhart wrote: >>> On Thu, Dec 20, 2012 at 11:26 AM, Gilles Sadowski < >>> gil...@harfang.homelinux.org> wrote: >>> Hi. Please have a look at the next candidate (RC5), and vote for the >> release of Commons Math 3.1. -- Tag: >> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_1_RC5/ Site: http://people.apache.org/builds/commons/math/3.1/RC5/ Binaries: >> https://repository.apache.org/content/repositories/orgapachecommons-052/org/apache/commons/commons-math3/3.1/ [ ] +1 Release it. [ ] +0 Go ahead; I don't care. [ ] -0 There are a few minor glitches: ... [ ] -1 No, do not release it because ... This vote will close in 72 hours. -- >>> Hi, >>> >>> this is not yet my vote, just a request for clarification. >>> >>> I checked again the Clirr errors, and there are still the two related to >>> the probability method in LogNormal and NormalDistribution. >>> >>> In 3.0, there was a method with only 1 parameter, which always returned >> 0. >>> Now there is a probability method with two parameters, which is defined >> in >>> the implemented interface AbstractRealDistribution. >> And... there is a method with one parameter that always return zero in the >> _parent_ class. Any code the calls the one-arg "probablility" method will >> get the same result (i.e zero) as before. >> >>> You mentioned that this is a false positive, but I doubt this. >> Why? >> >>> Maybe the >>> probability method was never used, >> It was not used in CM, but that would not be a good excuse I guess. ;-) >> >>> but then it should at least be mentioned >>> in the release notes. >> As I indicated previously, if this is a false positive, there is doubtful >> usefulness to explaining a bug in a reporting tool. >> > Hi Gilles, > > you are right, sorry I missed the inherited method. I think Clirr was not able to handle the fact that in 3.0 the single-argument version was implemented in these classes. In 3.1 a default impl was provided in the parent and these classes dropped local impls. So if you just look at the classes Clirr is complaining about before and after it looks like we just added an argument. Phil > > So then +1 from my side too. > > Thomas > - 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 - Build using Java 1.6
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=25554&projectId=75 Build statistics: State: Failed Previous State: Failed Started at: Fri 21 Dec 2012 21:20:02 + Finished at: Fri 21 Dec 2012 21:21:41 + Total time: 1m 38s Build Trigger: Schedule Build Number: 165 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: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Fri 21 Dec 2012 20:40:49 + Comment: [DIGESTER-173] No way to enable schema validation from DigesterLoader - patch provided by Ivan Diana Files changed: /commons/proper/digester/trunk/core/src/main/java/org/apache/commons/digester3/Digester.java ( 1425132 ) /commons/proper/digester/trunk/core/src/main/java/org/apache/commons/digester3/binder/DigesterLoader.java ( 1425132 ) /commons/proper/digester/trunk/core/src/test/java/org/apache/commons/digester3/DTDValidationTestCase.java ( 1425132 ) /commons/proper/digester/trunk/core/src/test/resources/org/apache/commons/digester3/document-with-relative-dtd-error.xml ( 1425132 ) /commons/proper/digester/trunk/pom.xml ( 1425132 ) /commons/proper/digester/trunk/src/changes/changes.xml ( 1425132 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Build using Java 1.6 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: [functor] Using [fucntor] functional interfaces with Java 8 lambdas
AMAZING
congrats Bruno!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Dec 21, 2012 at 8:22 PM, Bruno P. Kinoshita
wrote:
> Hi all,
>
> Just wanted to let you guys know that I am successfully compiling and
> executing code using [functor] and Java 8. And am also using [functor]
> functional interfaces with lambdas.
>
> So instead of writing:
>
>
> UnaryPredicate isEven = new UnaryPredicate() {
> public boolean test(Integer obj) {
> return obj % 2 == 0;
> }
> };
>
> One can simply write:
>
> UnaryPredicate isEven = (Integer obj) -> { return obj % 2 == 0; };
>
> FWIW, Google Guava's Predicate [1] is not a functional interface, so it
> cannot be used with lambdas, as in the example above.
>
> I'll continue to experiment with [functor] and Java 8. There are only two
> open issues in Jira, one regarding generators (there's a branch with a
> proposal implementation) and another one about the equals() method in the
> [functor] API.
>
> I wrote a short blog post [2] about how I'm running Java 8 in Eclipse Juno,
> in case anyone is interested in trying it too. The code is hosted at GitHub
> [3].
>
> Cheers,
>
> [1]
> http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/Predicate.java
> [2]
> http://www.kinoshita.eti.br/2012/12/21/using-apache-commons-functor-functional-interfaces-with-java-8-lambdas/
> [3] https://github.com/kinow/try-lambdas
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
> -
> 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
[digester] dropping the annotations-processor module
Hi all guys! the annotations-processor module in Digester has been in a prototypal status for a long time and I haven't had time/chances to make it working, so, since it has never been released before and I am busy as heel and won't have the opportunity to work on it, unless someone submits a patch to DIGESTER-158, I would be for dropping it and make the build work (and possibly cut a release). Any objection? Many thanks in advance, 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: [Math] Request for future releases: kill Cobertura
2012/12/21 Phil Steitz :
> On 12/21/12 10:53 AM, Sébastien Brisard wrote:
>> Hi,
>>
>>
>> 2012/12/21 Olivier Lamy
>>
>>> -Dcobertura.skip=true ?
>>> or in pom.properties
>>> true
>>>
>>> I agree with Phil, both options lead to strange error messages (see my
>> post above). Should it be considered as a bug of the cobertura plugin?
>
This one is a bit special as it fork a lifecycle but due to the skip
option the forked lifecycle is not complete so the error below.
I don't have any workaround to prevent that.
So the best is to remove the plugin
> Looks like the plugin is definitely broken. I get this with the
> command-line option above:
>
> *[INFO] [cobertura:instrument {execution: default-instrument}]
> [INFO] Skipping cobertura execution
> [debug] execute contextualize
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 28 resources
> [INFO] Copying 2 resources to META-INF
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> /Users/psteitz/newMath/trunk/target/surefire-reports
>
> ---
> T E S T S
> ---
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/math3/exception/DimensionMismatchException
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> at java.lang.Class.getMethod0(Class.java:2670)
>
>
> It is trying to needlessly execute the tests the second time as if
> it were generating the cobertura report.
>
> I really wish we could just drop this and the other reporting
> plugins from the parent and have components add the ones they want.
> In our [math] pom, we add configs for several of them anyway.
>
> Phil
> *
>>
>> Sébastien
>>
>> 2012/12/21 Phil Steitz :
>>
On 12/20/12 1:25 PM, Olivier Lamy wrote:
> 2012/12/20 Luc Maisonobe :
>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>>> 2012/12/20 luc
>>>
Le 2012-12-20 15:01, Phil Steitz a écrit :
On 12/19/12 6:19 PM, Gilles Sadowski wrote:
>> Hello.
>>
Hi all,
>> The situation with "Cobertura" is fairly annoying, perhaps
>>> particularly
>> so
>> for Commons Math because of the size of the code base (and thus the
>> fairly
>> large number of unit tests).
>>
>> As it just happened, a few minor problems have now delayed the
>>> release by
>> several days because I have to wait about 4 hours for the site
>>> generation
>> to complete (on a _fast_ machine).
>> Hence the request to remove Cobertura from the "site" target, or
>>> at least
>> from the "site:stage-deploy" step, so that a new vote can take
>>> place as
>> soon
>> as a problem is fixed.
>> [I would even argue that it is not that useful to include
>>> Cobertura in
>> the
>> release process because the amount of code coverage is not acted
>>> upon
>> (i.e.
>> low coverage would not block a release IIUC).]
>>
>> Do you agree?
>>
> +1
>
>> If so, can we change that for Commons Math only, or should this be
>>> done
>> at
>> the "parent" level? Is is just a matter of adding
>> true
>> in a new profile?
>>
> This is an argument that we have from time to time. IMO the parent
> should contain a minimal set of plugins and component POMs should
> explicitly include the ones they want. I would be +1 for dropping
> Coberta from the parent pom.
>
I will play devils adv
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Build using Java 1.6
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=2&projectId=75 Build statistics: State: Failed Previous State: Failed Started at: Fri 21 Dec 2012 22:20:02 + Finished at: Fri 21 Dec 2012 22:20:36 + Total time: 34s Build Trigger: Schedule Build Number: 165 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: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: "unix" SCM Changes: Changed: simonetripodi @ Fri 21 Dec 2012 21:27:00 + Comment: [DIGESTER-175] Regression: DigesterTestCase#testPopNamedStackNotPushed expects EmptyStackException Files changed: /commons/proper/digester/trunk/core/src/main/java/org/apache/commons/digester3/Digester.java ( 1425150 ) /commons/proper/digester/trunk/src/changes/changes.xml ( 1425150 ) Changed: simonetripodi @ Fri 21 Dec 2012 21:30:59 + Comment: [DIGESTER-170] Digester.pop(String) throws EmptyStackException where API doc says it returns null Files changed: /commons/proper/digester/trunk/core/src/main/java/org/apache/commons/digester3/Digester.java ( 1425151 ) Changed: simonetripodi @ Fri 21 Dec 2012 22:02:44 + Comment: added missing 'Apache' prefix in pom.name, present in all other digester poms Files changed: /commons/proper/digester/trunk/dist/pom.xml ( 1425161 ) /commons/proper/digester/trunk/examples/pom.xml ( 1425161 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Build using Java 1.6 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
[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) 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-dbcp has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 89 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-dbcp : Object Pooling - db-ddlutils : Easy-to-use component for working with Database Definition (... - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-dbcp : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers - javax.el : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - javax.servlet : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - javax.servlet.jsp : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - solr : Java Based Search Engine - solr-test : Java Based Search Engine - tomcat-tc6 : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - tomcat-tc7.0.x : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-dbcp : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-trunk : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-dbcp : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/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-dbcp.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml dist [Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-22122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-22122012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar - [javac]^ [javac] where T is a type-variable: [javac] T extends Object declared in method getObject(String,Class) [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65: error: DelegatingConnection is not abstract and does not override abstract method getNetworkTimeout() in Connection [javac] public class DelegatingConnection extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38: error: DelegatingDatabaseMetaData is not abstract and does not override abstract method generatedKeyAlwaysReturned() in DatabaseMetaData [javac] public class DelegatingDatabaseMetaData extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61: error: DelegatingResultSet is not abstract and does not override abstract method getObject(String,Class) in ResultSet [javac] public class DelegatingResultSet extends Aban
[GUMP@vmgump]: Project commons-dbcp2 (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-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 258 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 : Database Connection Pool
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/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-dbcp2-*[0-9T].jar] identifier set to project
name
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true
-Dbuild.sysclasspath=only
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml
dist
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH:
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-22122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-22122012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir:
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
error: BasicDataSource is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
error: DelegatingConnection is not abstract and does not override abstract
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
error: DelegatingStatement is not abstract and does not override abstract
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements
Statement {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
error: DelegatingPreparedStatement is not abstract and does not override
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
error: DelegatingCallableStatement is not abstract and does not override
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends
DelegatingPreparedStatement
[javac]^
[javac] where T is a type-variable:
[javac] T extends Object declared in method
getObject(String,Class)
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
error: DelegatingDatabaseMetaData is not abstract and does not override
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public cla
[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 89 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: 55 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] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1356148463553
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 3 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.Generated
[GUMP@vmgump]: Project commons-chain2 (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-chain2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 280 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-chain2 : GoF "Chain of Responsibility" pattern Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/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-chain2-*[0-9T].jar] identifier set to project name -DEBUG- Sole pom output [pom.xml] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/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-chain2/gump_work/build_apache-commons_commons-chain2.html Work Name: build_apache-commons_commons-chain2 (Type: Build) Work ended in a state of : Failed Elapsed: 51 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/chain] M2_HOME: /opt/maven2 - [INFO] Building war: /srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war [INFO] [INFO] Building Apache Commons Chain :: Distribution Packages [INFO]task-segment: [package] [INFO] [INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT 2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2), gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 50 seconds [INFO] Finished at: Sat Dec 22 04:32:03 UTC 2012 [INFO] Final Memory: 96M/230M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/atom.
[GUMP@vmgump]: Project commons-dbutils (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-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 258 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils : Commons DbUtils
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/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-dbutils-*[0-9T].jar] identifier set to
project name
-INFO- Optional dependency mockito failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
-WARNING- No directory
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded (mockito-core-1.9.0.pom)
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded (hamcrest-all-1.1.pom)
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded (hamcrest-all-1.1.jar)
1381K downloaded (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
main:
[copy] Copying 2 files to
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo:
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1356153649414
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 30 source files to
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO]
[INFO] For more information, run Mav
[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 94 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: 15 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 - Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Results : Tests in error: testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter) testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter) testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter) testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter) testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory) testCreateNullObject(org.apache.commons.proxy.TestProxyUtils) testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils) Tests run: 179, Failures: 0, Errors: 28, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There
[GUMP@vmgump]: Project commons-scxml-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-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 263 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-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/scxml/gump_mvn_settings.xml]
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info
--settings
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from =
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.293 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from =
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element in namespace
"http://my.foo.example/"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element in namespace
"http://my.foo.example/"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null):
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from =
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.061 sec
Results :
Failed tests:
testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)
Tests run: 229, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO
