Re: [Vote] Release Commons VFS 2.0
None were blockers btw. The only really important one is: >> Mention the package name change on the frontpage. Also that this means >> you can run both versions side by side. > > Did you read the News section? Isn't that clear? And the answer there is nope, didn't see it. Eyes weren't working. :) Hen On Sat, Aug 20, 2011 at 2:19 PM, Ralph Goers wrote: > Notes below. > On Aug 20, 2011, at 1:54 PM, Henri Yandell wrote: > >> I'll try to dig deeper, but don't wait on me. >> >> On the website: >> >> This is a bad page. A user clicks 'examples' and gets a blank page >> (pretty much): >> >> http://people.apache.org/~rgoers/commons-vfs/site/commons-vfs2-examples/index.html > > When you said "bad page" I thought the link was broken or something. I guess > you mean "poor page" in that it doesn't contain good content. I agree with > that but wouldn't consider that to be a blocker. > >> >> Clirr reports would be nice to show the API change. You'll have to be >> somewhat manual to deal with the package change (ie: checkout the >> current code, search and replace the package name back and rebuild >> with clirr reports). > > Is it really worth all that effort? The release notes say the package name > changed. If I could configure the maven plugin to do that it might have > considered it. > >> >> Checkstyle needs configuring to ignore all the 'magic numbers'. > > I disagree with this. I fixed way over 10,000 checkstyle errors. I didn't get > to these because they are tedious and I don't know what all those magic > numbers mean. However, I agree with checkstyle that they should be fixed. > I'd rather have the errors in the report so that maybe it bugs someone to fix > them than just ignore them. > >> >> Couple of high rated issues in Findbugs to fix in subsequent release. > > Agree - I fixed other errors Findbugs found but the fixes for those two > weren't clear to me. One complains about using a Random once (what is wrong > with that?). > >> >> Mention the package name change on the frontpage. Also that this means >> you can run both versions side by side. > > Did you read the News section? Isn't that clear? > > Ralph > > > > - > 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: [bcel] Backwards Incompatible Change to Visitor
Sebb is right... my mistake... apologies, and thanks for the fix. dave On 08/20/2011 09:15 PM, sebb wrote: On 17 August 2011 07:06, Stefan Bodewig wrote: Hi, with svn revision 1158060 the bcel.generic.Visitor interface has become package private, breaking the Gump builds of Xalan XSLTC, commons-javaflow and likely other downstream code. Has this change been intentional? I don't think so. The rest of the commit just removes public from methods. I assume that was a mistake to change the interface itself, as it does not agree with the log message. I've reverted the change of interface visibilty. Stefan - 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: [bcel] Backwards Incompatible Change to Visitor
On 17 August 2011 07:06, Stefan Bodewig wrote: > Hi, > > with svn revision 1158060 the bcel.generic.Visitor interface has become > package private, breaking the Gump builds of Xalan XSLTC, > commons-javaflow and likely other downstream code. > > Has this change been intentional? I don't think so. The rest of the commit just removes public from methods. I assume that was a mistake to change the interface itself, as it does not agree with the log message. I've reverted the change of interface visibilty. > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Commons VFS 2.0
On 20 August 2011 21:54, Henri Yandell wrote: > I'll try to dig deeper, but don't wait on me. > > On the website: > > This is a bad page. A user clicks 'examples' and gets a blank page > (pretty much): > > http://people.apache.org/~rgoers/commons-vfs/site/commons-vfs2-examples/index.html > > Clirr reports would be nice to show the API change. You'll have to be > somewhat manual to deal with the package change (ie: checkout the > current code, search and replace the package name back and rebuild > with clirr reports). The shade plugin can be used for this - see https://issues.apache.org/jira/browse/VFS-344 > Checkstyle needs configuring to ignore all the 'magic numbers'. > > Couple of high rated issues in Findbugs to fix in subsequent release. > > Mention the package name change on the frontpage. Also that this means > you can run both versions side by side. > > Hen > > > On Thu, Aug 18, 2011 at 9:25 AM, Ralph Goers > wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> Changes made since the last candidate: >> >> * Removed the sandbox project from the delivery, except for the web site. >> * Updated README.txt to remove the existing text and add very basic build >> instructions. >> >> I have also removed files that shouldn't be present in the Maven repository >> from the staging repo, except for the distribution files which will be moved >> to the standard distribution location and not deployed to the Nexus >> repository when the artifacts are released. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [ ] -1 no, do not release it because. >> >> Ralph >> >> >> Tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ >> (revision 1159220). >> >> Site: http://people.apache.org/~rgoers/commons-vfs/site/ >> >> >> The artifacts have been staged to the org.apache.commons-052 (u:rgoers, >> a:99.180.69.21) repository. >> >> The Maven artifacts are at: >> >> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ >> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ >> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ >> https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-distribution/ >> >> and consist of >> >> archetype-catalog.xml >> commons-vfs2-examples-2.0-javadoc.jar >> commons-vfs2-examples-2.0-sources.jar.asc >> commons-vfs2-examples-2.0.pom >> commons-vfs2-examples-2.0-tests.jar >> commons-vfs2-examples-2.0-tests.jar.asc >> commons-vfs2-examples-2.0.jar.asc >> commons-vfs2-examples-2.0.pom.asc >> commons-vfs2-examples-2.0-javadoc.jar.asc >> commons-vfs2-examples-2.0.jar >> commons-vfs2-examples-2.0-sources.jar >> commons-vfs2-project-2.0.pom.asc >> commons-vfs2-project-2.0.pom >> commons-vfs2-distribution-2.0-src.tar.gz >> commons-vfs2-distribution-2.0-src.tar.gz.asc >> commons-vfs2-distribution-2.0-src.zip.asc >> commons-vfs2-distribution-2.0-bin.zip >> commons-vfs2-distribution-2.0-bin.tar.gz >> commons-vfs2-distribution-2.0-bin.tar.gz.asc >> commons-vfs2-distribution-2.0-src.zip >> commons-vfs2-distribution-2.0-bin.zip.asc >> commons-vfs2-2.0.pom.asc >> commons-vfs2-2.0-javadoc.jar >> commons-vfs2-2.0-tests.jar.asc >> commons-vfs2-2.0-tests.jar >> commons-vfs2-2.0.pom >> commons-vfs2-2.0.jar >> commons-vfs2-2.0-sources.jar.asc >> commons-vfs2-2.0-test-sources.jar.asc >> commons-vfs2-2.0.jar.asc >> commons-vfs2-2.0-sources.jar >> commons-vfs2-2.0-test-sources.jar >> commons-vfs2-2.0-javadoc.jar.asc > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] SimpleRegression
On 8/12/11 9:30 PM, Phil Steitz wrote:
> On 8/12/11 7:16 PM, Greg Sterijevski wrote:
>> Hello All,
>>
>> Before I chum the water with more JIRA tickets, I thought I would see
>> whether people thought this was important.
>>
>> In the SimpleRegression you have two methods:
>>
>> public void addData(double x, double y) {
>> ...some code that is not germane to discussion..
>>
>> if (n > 2) {
>> distribution = new TDistributionImpl(n - 2);
>> }
>> }
>>
>> public void removeData(double x, double y) {
>> ...some code that is not germane..
>>
>> if (n > 2) {
>> distribution = new TDistributionImpl(n - 2);
>> }
>> }
>> }
>>
>> >From the perspective of a user, you are likely to call add/remove repeatedly
>> before you ever need to check for statistical significance. Wouldn't it be
>> better to instantiate the TDistribution when it is needed?
>>
>> So you would have to make the following two methods a bit more complicated:
>>
>> public double getSlopeConfidenceInterval(double alpha)
>> throws MathException {
>> if (alpha >= 1 || alpha <= 0) {
>> throw new
>> OutOfRangeException(LocalizedFormats.SIGNIFICANCE_LEVEL,
>> alpha, 0, 1);
>> }
>> if( distribution == null || distribution.getDegreesOfFreedom() !=
>> n-2){
>> distribution = new TDistributionImpl(n - 2);
>> }
>> return getSlopeStdErr() *
>> distribution.inverseCumulativeProbability(1d - alpha / 2d);
>> }
>>
>> Similarly getSignificance() would have to be modified with the check of the
>> degrees of freedom of the distribution.
>>
>> There is nothing wrong with the current code, but making the change means
>> faster updates.
> Slightly, yes. There is not much code at all in the distribution
> constructor, but you are correct. Moreover, I can see now that the
> "immutability-everywhere" changes in trunk have made the code in the
> class a little funny. In versions <=2.2, the TDistribution used by
> the class was pluggable - i.e., there was a constructor that took at
> TDistribution as an argument, so if for some reason you wanted to
> use an impl different from TDistributionImpl, you could do that.
> There was also a setter for the distribution. In addition,
> TDistributionImpl itself was mutable, exposing a setDegreesOfFreedom
> method. So the distribution member was set at construction time and
> the data update methods called the setter for DF on the
> distribution. We decided to make the distributions immutable in 3.0
> (search the archives for discussion), so the current mods were done
> to basically accomplish that. But the code should be cleaned up.
> The constructor taking an int is meaningless and should be
> deprecated or removed (unfortunately, we added that in 2.2 and
> advertised it as a deprecation replacement for the version that took
> a distribution as parameter. We should have realized then that it
> was meaningless. My bad for missing that. I would favor dropping it
> in 3.0, since even if anyone is using it, it isn't doing anything
> meaningful for them.) Given that constructing a TDistributionImpl
> is trivial, we might as well eliminate the member field altogether
> and just create one when needed. If you agree and no one else
> objects, I will make these changes. Thanks for reviewing the code.
Tracked as MATH-648, fixed in r1159918.
Phil
>
> Phil
>> Thoughts?
>>
>> -Greg
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Commons VFS 2.0
Notes below. On Aug 20, 2011, at 1:54 PM, Henri Yandell wrote: > I'll try to dig deeper, but don't wait on me. > > On the website: > > This is a bad page. A user clicks 'examples' and gets a blank page > (pretty much): > > > http://people.apache.org/~rgoers/commons-vfs/site/commons-vfs2-examples/index.html When you said "bad page" I thought the link was broken or something. I guess you mean "poor page" in that it doesn't contain good content. I agree with that but wouldn't consider that to be a blocker. > > Clirr reports would be nice to show the API change. You'll have to be > somewhat manual to deal with the package change (ie: checkout the > current code, search and replace the package name back and rebuild > with clirr reports). Is it really worth all that effort? The release notes say the package name changed. If I could configure the maven plugin to do that it might have considered it. > > Checkstyle needs configuring to ignore all the 'magic numbers'. I disagree with this. I fixed way over 10,000 checkstyle errors. I didn't get to these because they are tedious and I don't know what all those magic numbers mean. However, I agree with checkstyle that they should be fixed. I'd rather have the errors in the report so that maybe it bugs someone to fix them than just ignore them. > > Couple of high rated issues in Findbugs to fix in subsequent release. Agree - I fixed other errors Findbugs found but the fixes for those two weren't clear to me. One complains about using a Random once (what is wrong with that?). > > Mention the package name change on the frontpage. Also that this means > you can run both versions side by side. Did you read the News section? Isn't that clear? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Commons VFS 2.0
I'll try to dig deeper, but don't wait on me. On the website: This is a bad page. A user clicks 'examples' and gets a blank page (pretty much): http://people.apache.org/~rgoers/commons-vfs/site/commons-vfs2-examples/index.html Clirr reports would be nice to show the API change. You'll have to be somewhat manual to deal with the package change (ie: checkout the current code, search and replace the package name back and rebuild with clirr reports). Checkstyle needs configuring to ignore all the 'magic numbers'. Couple of high rated issues in Findbugs to fix in subsequent release. Mention the package name change on the frontpage. Also that this means you can run both versions side by side. Hen On Thu, Aug 18, 2011 at 9:25 AM, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > Changes made since the last candidate: > > * Removed the sandbox project from the delivery, except for the web site. > * Updated README.txt to remove the existing text and add very basic build > instructions. > > I have also removed files that shouldn't be present in the Maven repository > from the staging repo, except for the distribution files which will be moved > to the standard distribution location and not deployed to the Nexus > repository when the artifacts are released. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because. > > Ralph > > > Tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ > (revision 1159220). > > Site: http://people.apache.org/~rgoers/commons-vfs/site/ > > > The artifacts have been staged to the org.apache.commons-052 (u:rgoers, > a:99.180.69.21) repository. > > The Maven artifacts are at: > > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-distribution/ > > and consist of > > archetype-catalog.xml > commons-vfs2-examples-2.0-javadoc.jar > commons-vfs2-examples-2.0-sources.jar.asc > commons-vfs2-examples-2.0.pom > commons-vfs2-examples-2.0-tests.jar > commons-vfs2-examples-2.0-tests.jar.asc > commons-vfs2-examples-2.0.jar.asc > commons-vfs2-examples-2.0.pom.asc > commons-vfs2-examples-2.0-javadoc.jar.asc > commons-vfs2-examples-2.0.jar > commons-vfs2-examples-2.0-sources.jar > commons-vfs2-project-2.0.pom.asc > commons-vfs2-project-2.0.pom > commons-vfs2-distribution-2.0-src.tar.gz > commons-vfs2-distribution-2.0-src.tar.gz.asc > commons-vfs2-distribution-2.0-src.zip.asc > commons-vfs2-distribution-2.0-bin.zip > commons-vfs2-distribution-2.0-bin.tar.gz > commons-vfs2-distribution-2.0-bin.tar.gz.asc > commons-vfs2-distribution-2.0-src.zip > commons-vfs2-distribution-2.0-bin.zip.asc > commons-vfs2-2.0.pom.asc > commons-vfs2-2.0-javadoc.jar > commons-vfs2-2.0-tests.jar.asc > commons-vfs2-2.0-tests.jar > commons-vfs2-2.0.pom > commons-vfs2-2.0.jar > commons-vfs2-2.0-sources.jar.asc > commons-vfs2-2.0-test-sources.jar.asc > commons-vfs2-2.0.jar.asc > commons-vfs2-2.0-sources.jar > commons-vfs2-2.0-test-sources.jar > commons-vfs2-2.0-javadoc.jar.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Commons VFS 2.0
On 8/18/11 9:25 AM, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > Changes made since the last candidate: > > * Removed the sandbox project from the delivery, except for the web site. > * Updated README.txt to remove the existing text and add very basic build > instructions. > > I have also removed files that shouldn't be present in the Maven repository > from the staging repo, except for the distribution files which will be moved > to the standard distribution location and not deployed to the Nexus > repository when the artifacts are released. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because. +1 Sigs, hashes are good. Release contents look good. Build succeeds for me on the following JDKs: Ubuntu 10.04 --- Sun 1.5.0_22 java version "1.5.0_22" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03) Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode, sharing) Sun 1.6.0_17 java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing) Jrockit 1.5.0 java version "1.5.0_19" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02) BEA JRockit(R) (build R27.6.5-32_o-121899-1.5.0_19-20091001-2113-linux-ia32, compiled mode) Jrockit 1.6.0 java version "1.6.0_14" Java(TM) SE Runtime Environment (build 1.6.0_14-b08) BEA JRockit(R) (build R27.6.5-32_o-121899-1.6.0_14-20091001-2113-linux-ia32, compiled mode) --- Apple OS X 10.7.1 --- java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode) --- Phil > > Ralph > > > Tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ > (revision 1159220). > > Site: http://people.apache.org/~rgoers/commons-vfs/site/ > > > The artifacts have been staged to the org.apache.commons-052 (u:rgoers, > a:99.180.69.21) repository. > > The Maven artifacts are at: > > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ > https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-distribution/ > > and consist of > > archetype-catalog.xml > commons-vfs2-examples-2.0-javadoc.jar > commons-vfs2-examples-2.0-sources.jar.asc > commons-vfs2-examples-2.0.pom > commons-vfs2-examples-2.0-tests.jar > commons-vfs2-examples-2.0-tests.jar.asc > commons-vfs2-examples-2.0.jar.asc > commons-vfs2-examples-2.0.pom.asc > commons-vfs2-examples-2.0-javadoc.jar.asc > commons-vfs2-examples-2.0.jar > commons-vfs2-examples-2.0-sources.jar > commons-vfs2-project-2.0.pom.asc > commons-vfs2-project-2.0.pom > commons-vfs2-distribution-2.0-src.tar.gz > commons-vfs2-distribution-2.0-src.tar.gz.asc > commons-vfs2-distribution-2.0-src.zip.asc > commons-vfs2-distribution-2.0-bin.zip > commons-vfs2-distribution-2.0-bin.tar.gz > commons-vfs2-distribution-2.0-bin.tar.gz.asc > commons-vfs2-distribution-2.0-src.zip > commons-vfs2-distribution-2.0-bin.zip.asc > commons-vfs2-2.0.pom.asc > commons-vfs2-2.0-javadoc.jar > commons-vfs2-2.0-tests.jar.asc > commons-vfs2-2.0-tests.jar > commons-vfs2-2.0.pom > commons-vfs2-2.0.jar > commons-vfs2-2.0-sources.jar.asc > commons-vfs2-2.0-test-sources.jar.asc > commons-vfs2-2.0.jar.asc > commons-vfs2-2.0-sources.jar > commons-vfs2-2.0-test-sources.jar > commons-vfs2-2.0-javadoc.jar.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[configuration] CONFIGURATION-427 - WAS Steps towards next release
Am 17.08.2011 00:04, schrieb Emmanuel Bourg: Le 16/08/2011 22:27, Oliver Heger a écrit : Aren't we free to decide how to represent data structures in a configuration? I mean, the dot keys used by XMLConfiguration is also just a convention. We could transform a plist file to a XML-friendly structure and store it in a hierarchical configuration. We just have to document how to access list structures. We could then add specialized convenience methods to PListConfiguration for accessing lists in a way more intuitive for plist users. Wouldn't this be an option? Our plist configurations are already hierarchical. The difference lies in the way the lists are stored. In the XML way a list is typically structured as: root list element -> value1 element -> value2 element -> value3 In the plist way it's structured as: root list -> [value1, value2, value3] My understanding is that in a plist file a path can't be used more than once. So if you explode the structure of a list to put one element per node, you have to reverse the operation and regroup sibling nodes into a list when the configuration is written. Headache guaranteed for the implementer :) Yes, it would certainly mean more effort on implementation side, but it would also gain some benefits for users. We do transformations for other configuration implementations, too, e.g. in HierarchicalINIConfiguration. Well, the transformation for plist configurations seems to be more complex. That said, I am not against the patch. If you think it works for most of the users, just go ahead and commit it. Alternatively we could postpone this issue to the next release, so there is more time to think about a solution. I am still on the opinion that it makes sense to get out a binary compatible release soon which has been updated for Java 1.5. Here the fix could be included. Oliver Emmanuel Bourg - 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
[configuration] Deprecate ConfigurationFactory?
In CONFIGURATION-459 the user guide has been re-written so that ConfigurationFactory is no more mentioned. Do we all agree that ConfigurationFactory should be deprectated in favor of DefaultConfigurationBuilder? Should we do the deprecation in the upcoming 1.7 release? Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[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 48 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.155 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Sat Aug 20 11:41:42 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.or
[GUMP@vmgump]: Project commons-javaflow (in module commons-sandbox) 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-javaflow has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 8 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-javaflow : Commons Javaflow
Full details are available at:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/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-javaflow-*[0-9T].jar] identifier set to
project name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/commons-sandbox/javaflow/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/commons-sandbox/javaflow/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/commons-sandbox/javaflow/target/surefire-reports
-WARNING- No directory
[/srv/gump/public/workspace/commons-sandbox/javaflow/target/surefire-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/gump_work/build_commons-sandbox_commons-javaflow.html
Work Name: build_commons-sandbox_commons-javaflow (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/commons-sandbox/javaflow/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/commons-sandbox/javaflow]
M2_HOME: /opt/maven2
-
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons Javaflow (Sandbox)
[INFO]task-segment: [package]
[INFO]
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/srv/gump/public/workspace/commons-sandbox/javaflow/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[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] Compiling 35 source files to
/srv/gump/public/workspace/commons-sandbox/javaflow/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/commons-sandbox/javaflow/src/main/java/org/apache/commons/javaflow/bytecode/transformation/bcel/analyser/ExecutionVisitor.java:[57,62]
org.apache.bcel.generic.Visitor is not public in org.apache.bcel.generic;
cannot be accessed from outside package
[INFO] 1error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/commons-sandbox/javaflow/src/main/java/org/apache/commons/javaflow/bytecode/transformation/bcel/analyser/ExecutionVisitor.java:[57,62]
org.apache.bcel.generic.Visitor is not public in org.apache.bcel.generic;
cannot be accessed from outside package
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 9 seconds
[INFO] Finished at: Sat Aug 20 11:40:16 UTC 2011
[INFO] Final Memory: 22M/60M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/atom.xml
== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 05000620082011, vmgump.apache.org:vmgum
Re: [DBUTILS] Test code still requires Java 1.6
On 20 August 2011 10:50, Olivier Lamy wrote: > Hello > Why not using the animal sniffer plugin in the build ? Continuum already detects such issues, provided that the correct build profile is used. Seems like overkill to add another plugin. > -- > Olivier > Le 20 août 2011 09:56, "Henri Yandell" a écrit : >> Thanks. It was an unused import, so I've removed it. It also showed >> up in javadoc and I've fixed that too. Sorry, could have fixed that myself - for some reason I thought the import was needed. >> >> Hen >> >> On Fri, Aug 19, 2011 at 8:00 AM, sebb wrote: >>> QueryRunnerTest imports java.util.concurrent.RunnableFuture which >>> requires Java 1.6 >>> >>> - >>> 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: [DBUTILS] Test code still requires Java 1.6
Hello Why not using the animal sniffer plugin in the build ? -- Olivier Le 20 août 2011 09:56, "Henri Yandell" a écrit : > Thanks. It was an unused import, so I've removed it. It also showed > up in javadoc and I've fixed that too. > > Hen > > On Fri, Aug 19, 2011 at 8:00 AM, sebb wrote: >> QueryRunnerTest imports java.util.concurrent.RunnableFuture which >> requires Java 1.6 >> >> - >> 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: [continuum] BUILD FAILURE: Apache Commons - Commons DbUtils - Default Maven 2 Build Definition (Java 1.5)
Thanks :) On Fri, Aug 19, 2011 at 8:09 AM, sebb wrote: > Removed the definition as I see you are now aiming for 1.5 again. > > > On 19 August 2011 15:52, sebb wrote: >> Failure was due to requiring Java 1.6; the Commons Continnum default is 1.5. >> >> I've added a local build definition for DbUtils and it builds OK now. >> >> On 19 August 2011 08:22, Continuum@vmbuild wrote: >>> Online report : >>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=11469&projectId=74 >>> >>> Build statistics: >>> State: Failed >>> Previous State: Failed >>> Started at: Fri 19 Aug 2011 07:22:21 + >>> Finished at: Fri 19 Aug 2011 07:22:37 + >>> Total time: 15s >>> Build Trigger: Schedule >>> Build Number: 12 >>> Exit code: 1 >>> Building machine hostname: vmbuild >>> Operating system : Linux(unknown) >>> Java Home version : >>> java version "1.6.0_24" >>> Java(TM) SE Runtime Environment (build 1.6.0_24-b07) >>> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >>> >>> Builder version : >>> Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) >>> Java version: 1.6.0_24 >>> Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre >>> Default locale: en_AU, platform encoding: UTF-8 >>> OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: >>> "unix" >>> >>> >>> SCM Changes: >>> >>> Changed: bayard @ Fri 19 Aug 2011 06:30:47 + >>> Comment: Rolling back to JDK 1.5 per DBUTILS-78 >>> Files changed: >>> /commons/proper/dbutils/trunk/pom.xml ( 1159516 ) >>> >>> >>> Dependencies Changes: >>> >>> No dependencies changed >>> >>> >>> >>> Build Definition: >>> >>> POM filename: pom.xml >>> Goals: clean deploy >>> Arguments: --batch-mode -Pjava-1.5 >>> Build Fresh: false >>> Always Build: false >>> Default Build Definition: true >>> Schedule: COMMONS_SCHEDULE >>> Profile Name: Maven 2.2.1 >>> Description: Default Maven 2 Build Definition (Java 1.5) >>> >>> >>> Test Summary: >>> >>> Tests: 0 >>> Failures: 0 >>> Errors: 0 >>> Total time: 0.0 >>> >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > > - > 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: [DBUTILS] Test code still requires Java 1.6
Thanks. It was an unused import, so I've removed it. It also showed up in javadoc and I've fixed that too. Hen On Fri, Aug 19, 2011 at 8:00 AM, sebb wrote: > QueryRunnerTest imports java.util.concurrent.RunnableFuture which > requires Java 1.6 > > - > 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
