Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Thu, 2005-06-09 at 21:14 +0100, robert burrell donkin wrote: > On Thu, 2005-06-09 at 10:51 +1200, Simon Kitching wrote: > > On Wed, 2005-06-08 at 23:22 +0100, robert burrell donkin wrote: > > > > > > > === other > > > > > > > > The src distro builds fine with Java1.5 on Linux (debian 3.1). > > > > > > > > Unfortunately, there are ?? unit test failures when using java 1.3.1: > > > > TEST org.apache.commons.betwixt.strategy.TestConversionFlavour FAILED > > > > TEST org.apache.commons.betwixt.schema.TestSchemaGeneration FAILED > > > > TEST org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping FAILED > > > > TEST org.apache.commons.betwixt.io.read.TestMaps FAILED > > > > TEST org.apache.commons.betwixt.recursion.TestSharedIDGeneration FAILED > > > > TEST org.apache.commons.betwixt.derived.TestWriteClass FAILED > > > > > > > > They look like real failures; some of the output is shown below. > > > > > > not sure whether they are real failures or not. a lot of the tests are > > > *very* sensitive to changes in undocumented introspection symantics > > > (such as ordering of methods) and have had a history of failing on > > > different JVM's. i would have expected to have had some feedback from > > > users by now if there were major problems on 1.5. > > > > > > i'm inclined to push this release out as is since there are users who > > > need a formal release with the extra functionality urgently and worry > > > about 1.5 compatibility later. > > > > The info above shows that the tests *work* on 1.5, but *fail* on 1.3. > > knew i should have turned in earlier :) > > > As you say, these are probably due to method ordering and are problems > > with the tests rather than with the code. But it's hard to be sure. > > > > At the very least, I think the release notes need to state that this > > release may not work on java 1.3. > > i think thomas is right and probably this should be the 1.7 release > (rather than 1.6.1) which means a vote. so, everything will be delayed a > few days. which will probably give me a chance to take a look into this > issue (i hope). all the test failures were due to changes to the algorithm used by sun to calculate default orders for property descriptors between 1.3.1 and 1.4. i've added code that should allow the tests to cope better. unfortunately, it's not a very satisfactory solution since the tests are now very hard to read. (there is a feature that's been needed for a while which would sidestep this issue but i didn't want to introduce code changes...) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Fri, 2005-06-10 at 10:33 +1200, Simon Kitching wrote: > On Thu, 2005-06-09 at 20:29 +0100, robert burrell donkin wrote: > > On Thu, 2005-06-09 at 10:41 +1200, Simon Kitching wrote: > > > On Wed, 2005-06-08 at 22:21 +0100, robert burrell donkin wrote: > > > > > > > > === > > > > > Maven reports: > > > > > > > > > > I would suggest disabling this report. Firstly, a log of the last 30 > > > > > days isn't of much use. And secondly, due to the import into SVN of > > > > > back-dated CVS changes, date-based selection on the apache subversion > > > > > repository is broken, so the report is not just useless but actively > > > > > WRONG. > > > > > > > > > > I suggest that "Developer Activity" and "File Activity" reports are > > > > > also > > > > > useless, and (if based on SVN date selection) also wrong. > > > > > > > > AIUI the problem occurs only with the dates on the imported data. new > > > > data is fine. i've checked the results and they look about right. i do > > > > agree that they aren't all that useful but i know some users like them > > > > so i'm inclined to keep them... > > > > > > Unfortunately the date problem is repository-wide, and long-lasting. > > > > > > When subversion is passed a date, it immediately converts this into a > > > revision-number. And it does this by performing a binary search on its > > > revisions. > > > > > > Assuming there are 1000 revisions currently in the repository, it > > > * checks whether revision 500 is earlier or later than the desired date > > > * 500 is earlier, so revision 750 is checked > > > * 750 is earlier, so 875 is checked > > > * 875 is later, so 812 is checked, etc > > > > > > This process is based on a fundamental assumption that revision X has an > > > earlier date than revision X+1. When this assumption is broken, the > > > binary search can go off in the wrong direction. And it looks to me like > > > after a "problem" import date selections will continue to be broken > > > until the revision# has at least doubled in size. > > > > > > Whether you actually get bitten by the problem for a particular > > > date-based select is a bit of a lottery; if the binary search happens to > > > hit "valid" nodes all the way down, the search will work correctly. But > > > hit the wrong node and the select can be a long way out. > > > > > > Alas, it is just not possible to "insert" revisions into an existing > > > repository; when importing data it can only be added as new revisions. > > > > > > So the current choice when importing CVS history is > > > (1) stuff up all date-based selections *repository-wide*, or > > > (2) discard all date information associated with imported CVS history, > > > and put "current" dates against the revisions. > > > > thanks for the detailed information > > > > once all the CVS repositories have been imported, this should no longer > > be a problem but until then i'll disable the reports. > > Alas, I don't think so. As I said above, I believe that after the last > CVS import has been done, we will then need to wait for the # of > revisions in the repository to double before date-based searching is > completely reliable again. > > I expect that the revision# will reach about 200,000 by the time > everything is imported into SVN. So when the count reaches 400,000 > everything will be right again. That should only take a decade or so :-( once all the projects have been imported, this issue should only effect the reliability of searches during the period before the date of the last import. the binary algorithm should work reliably for searches after that date. AFAIK the reports in question only required searches to function reliably for the last 30 days. (though the revisions with higher numbers during that period may have dates early than lower numbered revisions, all must have dates before the date being searched for. therefore, the binary algorithm should always choose the higher half until it reaches the region where the expected relationship holds. the binary algorithm will work as expected within this region and so the search should prove reliable for dates after the lat import.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Thu, 2005-06-09 at 20:29 +0100, robert burrell donkin wrote: > On Thu, 2005-06-09 at 10:41 +1200, Simon Kitching wrote: > > On Wed, 2005-06-08 at 22:21 +0100, robert burrell donkin wrote: > > > > > > === > > > > Maven reports: > > > > > > > > I would suggest disabling this report. Firstly, a log of the last 30 > > > > days isn't of much use. And secondly, due to the import into SVN of > > > > back-dated CVS changes, date-based selection on the apache subversion > > > > repository is broken, so the report is not just useless but actively > > > > WRONG. > > > > > > > > I suggest that "Developer Activity" and "File Activity" reports are also > > > > useless, and (if based on SVN date selection) also wrong. > > > > > > AIUI the problem occurs only with the dates on the imported data. new > > > data is fine. i've checked the results and they look about right. i do > > > agree that they aren't all that useful but i know some users like them > > > so i'm inclined to keep them... > > > > Unfortunately the date problem is repository-wide, and long-lasting. > > > > When subversion is passed a date, it immediately converts this into a > > revision-number. And it does this by performing a binary search on its > > revisions. > > > > Assuming there are 1000 revisions currently in the repository, it > > * checks whether revision 500 is earlier or later than the desired date > > * 500 is earlier, so revision 750 is checked > > * 750 is earlier, so 875 is checked > > * 875 is later, so 812 is checked, etc > > > > This process is based on a fundamental assumption that revision X has an > > earlier date than revision X+1. When this assumption is broken, the > > binary search can go off in the wrong direction. And it looks to me like > > after a "problem" import date selections will continue to be broken > > until the revision# has at least doubled in size. > > > > Whether you actually get bitten by the problem for a particular > > date-based select is a bit of a lottery; if the binary search happens to > > hit "valid" nodes all the way down, the search will work correctly. But > > hit the wrong node and the select can be a long way out. > > > > Alas, it is just not possible to "insert" revisions into an existing > > repository; when importing data it can only be added as new revisions. > > > > So the current choice when importing CVS history is > > (1) stuff up all date-based selections *repository-wide*, or > > (2) discard all date information associated with imported CVS history, > > and put "current" dates against the revisions. > > thanks for the detailed information > > once all the CVS repositories have been imported, this should no longer > be a problem but until then i'll disable the reports. Alas, I don't think so. As I said above, I believe that after the last CVS import has been done, we will then need to wait for the # of revisions in the repository to double before date-based searching is completely reliable again. I expect that the revision# will reach about 200,000 by the time everything is imported into SVN. So when the count reaches 400,000 everything will be right again. That should only take a decade or so :-( Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Thu, 2005-06-09 at 20:08 +0100, robert burrell donkin wrote: > On Wed, 2005-06-08 at 15:08 +1200, Simon Kitching wrote: > > On Mon, 2005-06-06 at 22:35 +0100, robert burrell donkin wrote: > > > The first public release candidate (RC3) for Betwixt 0.6.1 is now > > > available for download: > > > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > > > report any problems ASAP. > > > > I've run clirr to analyse the differences between releases 0.6 and > > 0.6.1. It all looks good. You might want to include this in the RC > > information so people can see that there are indeed no binary > > incompatibilities between these releases... > > > > http://people.apache.org/~skitching/betwixt-0.6-to-0.6.1-clirr.txt > > i ran clirr (too) using maven. i had hoped that it'd produce a neat > report that i could include in with the release documentation (but i > couldn't make it do so). Clirr is only half-finished unfortunately. Perhaps when commons-logging, digester and beanutils releases are all out the door I might have some time to get back to it. Despite the very plain output layout, however, it does provide useful information when preparing a release. In particular, any binary-incompatible changes should show up plainly in the output. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Thu, 2005-06-09 at 10:51 +1200, Simon Kitching wrote: > On Wed, 2005-06-08 at 23:22 +0100, robert burrell donkin wrote: > > > > > === other > > > > > > The src distro builds fine with Java1.5 on Linux (debian 3.1). > > > > > > Unfortunately, there are ?? unit test failures when using java 1.3.1: > > > TEST org.apache.commons.betwixt.strategy.TestConversionFlavour FAILED > > > TEST org.apache.commons.betwixt.schema.TestSchemaGeneration FAILED > > > TEST org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping FAILED > > > TEST org.apache.commons.betwixt.io.read.TestMaps FAILED > > > TEST org.apache.commons.betwixt.recursion.TestSharedIDGeneration FAILED > > > TEST org.apache.commons.betwixt.derived.TestWriteClass FAILED > > > > > > They look like real failures; some of the output is shown below. > > > > not sure whether they are real failures or not. a lot of the tests are > > *very* sensitive to changes in undocumented introspection symantics > > (such as ordering of methods) and have had a history of failing on > > different JVM's. i would have expected to have had some feedback from > > users by now if there were major problems on 1.5. > > > > i'm inclined to push this release out as is since there are users who > > need a formal release with the extra functionality urgently and worry > > about 1.5 compatibility later. > > The info above shows that the tests *work* on 1.5, but *fail* on 1.3. knew i should have turned in earlier :) > As you say, these are probably due to method ordering and are problems > with the tests rather than with the code. But it's hard to be sure. > > At the very least, I think the release notes need to state that this > release may not work on java 1.3. i think thomas is right and probably this should be the 1.7 release (rather than 1.6.1) which means a vote. so, everything will be delayed a few days. which will probably give me a chance to take a look into this issue (i hope). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Thu, 2005-06-09 at 10:41 +1200, Simon Kitching wrote: > On Wed, 2005-06-08 at 22:21 +0100, robert burrell donkin wrote: > > > > === > > > Maven reports: > > > > > > I would suggest disabling this report. Firstly, a log of the last 30 > > > days isn't of much use. And secondly, due to the import into SVN of > > > back-dated CVS changes, date-based selection on the apache subversion > > > repository is broken, so the report is not just useless but actively > > > WRONG. > > > > > > I suggest that "Developer Activity" and "File Activity" reports are also > > > useless, and (if based on SVN date selection) also wrong. > > > > AIUI the problem occurs only with the dates on the imported data. new > > data is fine. i've checked the results and they look about right. i do > > agree that they aren't all that useful but i know some users like them > > so i'm inclined to keep them... > > Unfortunately the date problem is repository-wide, and long-lasting. > > When subversion is passed a date, it immediately converts this into a > revision-number. And it does this by performing a binary search on its > revisions. > > Assuming there are 1000 revisions currently in the repository, it > * checks whether revision 500 is earlier or later than the desired date > * 500 is earlier, so revision 750 is checked > * 750 is earlier, so 875 is checked > * 875 is later, so 812 is checked, etc > > This process is based on a fundamental assumption that revision X has an > earlier date than revision X+1. When this assumption is broken, the > binary search can go off in the wrong direction. And it looks to me like > after a "problem" import date selections will continue to be broken > until the revision# has at least doubled in size. > > Whether you actually get bitten by the problem for a particular > date-based select is a bit of a lottery; if the binary search happens to > hit "valid" nodes all the way down, the search will work correctly. But > hit the wrong node and the select can be a long way out. > > Alas, it is just not possible to "insert" revisions into an existing > repository; when importing data it can only be added as new revisions. > > So the current choice when importing CVS history is > (1) stuff up all date-based selections *repository-wide*, or > (2) discard all date information associated with imported CVS history, > and put "current" dates against the revisions. thanks for the detailed information once all the CVS repositories have been imported, this should no longer be a problem but until then i'll disable the reports. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Wed, 2005-06-08 at 14:43 +0200, Thomas Dudziak wrote: > On 6/6/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > The first public release candidate (RC3) for Betwixt 0.6.1 is now > > available for download: > > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > > report any problems ASAP. > > I was wondering why you only increase the lowest version number ? From > the release description (esp. the semantic imcompatibilities) IMO it > would be justified to call the release 0.7 ?! good point. i didn't think that the semantic compatibilities were likely to have any effect in practice but list of added features is also pretty long. maybe it looks more like a 0.7... an additional vote will be needed to upgrade the version so it'll take a little longer... opinions anyone? > Btw, the SVN link does not work on the site: yep (i was hoping to have the release cut by now and had hoped to avoid conflicts during the merge but maybe i'll have to reconsider now...) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Wed, 2005-06-08 at 15:08 +1200, Simon Kitching wrote: > On Mon, 2005-06-06 at 22:35 +0100, robert burrell donkin wrote: > > The first public release candidate (RC3) for Betwixt 0.6.1 is now > > available for download: > > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > > report any problems ASAP. > > I've run clirr to analyse the differences between releases 0.6 and > 0.6.1. It all looks good. You might want to include this in the RC > information so people can see that there are indeed no binary > incompatibilities between these releases... > > http://people.apache.org/~skitching/betwixt-0.6-to-0.6.1-clirr.txt i ran clirr (too) using maven. i had hoped that it'd produce a neat report that i could include in with the release documentation (but i couldn't make it do so). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Wed, 2005-06-08 at 23:22 +0100, robert burrell donkin wrote: > > > === other > > > > The src distro builds fine with Java1.5 on Linux (debian 3.1). > > > > Unfortunately, there are ?? unit test failures when using java 1.3.1: > > TEST org.apache.commons.betwixt.strategy.TestConversionFlavour FAILED > > TEST org.apache.commons.betwixt.schema.TestSchemaGeneration FAILED > > TEST org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping FAILED > > TEST org.apache.commons.betwixt.io.read.TestMaps FAILED > > TEST org.apache.commons.betwixt.recursion.TestSharedIDGeneration FAILED > > TEST org.apache.commons.betwixt.derived.TestWriteClass FAILED > > > > They look like real failures; some of the output is shown below. > > not sure whether they are real failures or not. a lot of the tests are > *very* sensitive to changes in undocumented introspection symantics > (such as ordering of methods) and have had a history of failing on > different JVM's. i would have expected to have had some feedback from > users by now if there were major problems on 1.5. > > i'm inclined to push this release out as is since there are users who > need a formal release with the extra functionality urgently and worry > about 1.5 compatibility later. The info above shows that the tests *work* on 1.5, but *fail* on 1.3. As you say, these are probably due to method ordering and are problems with the tests rather than with the code. But it's hard to be sure. At the very least, I think the release notes need to state that this release may not work on java 1.3. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Wed, 2005-06-08 at 22:21 +0100, robert burrell donkin wrote: > > === > > Maven reports: > > > > I would suggest disabling this report. Firstly, a log of the last 30 > > days isn't of much use. And secondly, due to the import into SVN of > > back-dated CVS changes, date-based selection on the apache subversion > > repository is broken, so the report is not just useless but actively > > WRONG. > > > > I suggest that "Developer Activity" and "File Activity" reports are also > > useless, and (if based on SVN date selection) also wrong. > > AIUI the problem occurs only with the dates on the imported data. new > data is fine. i've checked the results and they look about right. i do > agree that they aren't all that useful but i know some users like them > so i'm inclined to keep them... Unfortunately the date problem is repository-wide, and long-lasting. When subversion is passed a date, it immediately converts this into a revision-number. And it does this by performing a binary search on its revisions. Assuming there are 1000 revisions currently in the repository, it * checks whether revision 500 is earlier or later than the desired date * 500 is earlier, so revision 750 is checked * 750 is earlier, so 875 is checked * 875 is later, so 812 is checked, etc This process is based on a fundamental assumption that revision X has an earlier date than revision X+1. When this assumption is broken, the binary search can go off in the wrong direction. And it looks to me like after a "problem" import date selections will continue to be broken until the revision# has at least doubled in size. Whether you actually get bitten by the problem for a particular date-based select is a bit of a lottery; if the binary search happens to hit "valid" nodes all the way down, the search will work correctly. But hit the wrong node and the select can be a long way out. Alas, it is just not possible to "insert" revisions into an existing repository; when importing data it can only be added as new revisions. So the current choice when importing CVS history is (1) stuff up all date-based selections *repository-wide*, or (2) discard all date information associated with imported CVS history, and put "current" dates against the revisions. The subversion developers are aware of this, and Ben Collins-Sussman has said that he would "love to add an index" to fix this. But I don't think it has very high priority. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Tue, 2005-06-07 at 22:37 +1200, Simon Kitching wrote: > === SRC tarball > > The -src download unpacks into a directory which does *not* have -src in > the name. This is the default behaviour of Maven, but not the way that > many other distributions work. I happen to like -src distros unpacking > into a directory different from the one the binary distro creates. It's > up to you which to choose, but if you want to have the src dir named > -src, then see commons-digester/maven.xml for one solution. i dislike the default chosen by maven (but thought that this was the way most mavenised commons components did it). directory name changed. BTW i've been working on an improved version of the release preparation document whilst creating this release. i'll try to remember to add this recommendation. > There is no build.properties.sample file in the src distro. If you are > providing a build.xml then a build.properties.sample is very useful. the build.xml is generated by maven and so should run correctly without a build.properties file. (it does for me.) > There is slightly odd indenting in the second-to-last line of > README.txt. And some slightly odd indenting in RELEASE-NOTES.txt too. > It's probably because there are tabs in the files, and I bet you have > tabwidth set to 4 on your machine. it's an old document. i considered replacing it but thought it better to push this release out. i'll probably rewrite it. > === > > Running "maven" in the src dir with java1.5 results in: > javac: target release 1.1 conflicts with default source release 1.5 > When you have > maven.target.compile=1.1 > in project.properties you also need > maven.target.source=1.2 > to avoid this problem. that's interesting. added. > Maven reports this when run: > java:jar: > [echo] java:jar is deprecated and will be removed. Please use > jar:jar > This can be fixed by updating maven.xml: > > should be > > unless there's something I don't know yep. committed. (but for some reason, i haven't had that message for a while on my system) > === Binary tarball > > The docs directory contains all the Maven reports, including the > "test-xref" and stuff. This is a very large volume of data that almost > nobody will want. I suggest removing this from the binary download. See > maven.xml in commons-digester for one way to solve this. i'll be rolling a jar-only distribution so those who want the minimum can download that. so, i'm inclined to leave the reports (unless there's a groundswell of opinion from others). > === other > > The src distro builds fine with Java1.5 on Linux (debian 3.1). > > Unfortunately, there are ?? unit test failures when using java 1.3.1: > TEST org.apache.commons.betwixt.strategy.TestConversionFlavour FAILED > TEST org.apache.commons.betwixt.schema.TestSchemaGeneration FAILED > TEST org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping FAILED > TEST org.apache.commons.betwixt.io.read.TestMaps FAILED > TEST org.apache.commons.betwixt.recursion.TestSharedIDGeneration FAILED > TEST org.apache.commons.betwixt.derived.TestWriteClass FAILED > > They look like real failures; some of the output is shown below. not sure whether they are real failures or not. a lot of the tests are *very* sensitive to changes in undocumented introspection symantics (such as ordering of methods) and have had a history of failing on different JVM's. i would have expected to have had some feedback from users by now if there were major problems on 1.5. i'm inclined to push this release out as is since there are users who need a formal release with the extra functionality urgently and worry about 1.5 compatibility later. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Tue, 2005-06-07 at 18:46 +1200, Simon Kitching wrote: > On Mon, 2005-06-06 at 22:35 +0100, robert burrell donkin wrote: > > The first public release candidate (RC3) for Betwixt 0.6.1 is now > > available for download: > > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > > report any problems ASAP. > > > > Hi Robert, > > Here's some stuff re the site. > > Many of these items are just minor typos, but I figured I may as well > pass on stuff once I'd spotted it. I don't mean to imply that all of > this needs fixing for 1.6.1! well spotted 8-) might as well get them fixed for the release... > === > The SVN link only goes to the viewcvs link. I suggest also having a link > to the "raw" URL for subversion. This is much more helpful for locating > the string a user needs to pass to the subversion client app to do a > checkout. makes sense. added. > Navbar: > Menu item "Outputing The Results" --> "Outputting The Results"? > Entry "Reading Beans(Advanced)" appears to be in bold for some reason (for me, at least) the entry is only bold when the page (in question) is being viewed. > === > Dependencies: > The bottom of the "tasks" page has > * Upgraded commons-beanutils to 1.6.1. > * Upgraded commons-digester to 1.5. > but the official Maven dependencies are beanutils-1.7 and digester-1.6 > respectively. i think that these updates were done for the last release but i've added notes for this release (to avoid any confusion). > === > Maven reports: > > I would suggest disabling this report. Firstly, a log of the last 30 > days isn't of much use. And secondly, due to the import into SVN of > back-dated CVS changes, date-based selection on the apache subversion > repository is broken, so the report is not just useless but actively > WRONG. > > I suggest that "Developer Activity" and "File Activity" reports are also > useless, and (if based on SVN date selection) also wrong. AIUI the problem occurs only with the dates on the imported data. new data is fine. i've checked the results and they look about right. i do agree that they aren't all that useful but i know some users like them so i'm inclined to keep them... > There are 28 warnings in the javadoc warnings report. i think you mean that there are a number of warnings about packages in the javadoc report. this is caused by break iterator warnings (which are 1.4.x only). happily, these were caused by a single sentence which contained a typo. fixing that made them go away. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On 6/6/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > The first public release candidate (RC3) for Betwixt 0.6.1 is now > available for download: > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > report any problems ASAP. I was wondering why you only increase the lowest version number ? From the release description (esp. the semantic imcompatibilities) IMO it would be justified to call the release 0.7 ?! Btw, the SVN link does not work on the site: An Exception Has Occurred jakarta-commons/betwixt: unknown location HTTP Response Status 404 Not Found Python Traceback Traceback (most recent call last): File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3345, in main request.run_viewcvs() File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 292, in run_viewcvs % self.where, '404 Not Found') ViewCVSException: 404 Not Found: jakarta-commons/betwixt: unknown location regards, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Mon, 2005-06-06 at 22:35 +0100, robert burrell donkin wrote: > The first public release candidate (RC3) for Betwixt 0.6.1 is now > available for download: > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > report any problems ASAP. I've run clirr to analyse the differences between releases 0.6 and 0.6.1. It all looks good. You might want to include this in the RC information so people can see that there are indeed no binary incompatibilities between these releases... http://people.apache.org/~skitching/betwixt-0.6-to-0.6.1-clirr.txt Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
Hi Robert, On Mon, 2005-06-06 at 22:35 +0100, robert burrell donkin wrote: > The first public release candidate (RC3) for Betwixt 0.6.1 is now > available for download: > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > report any problems ASAP. > === SRC tarball The -src download unpacks into a directory which does *not* have -src in the name. This is the default behaviour of Maven, but not the way that many other distributions work. I happen to like -src distros unpacking into a directory different from the one the binary distro creates. It's up to you which to choose, but if you want to have the src dir named -src, then see commons-digester/maven.xml for one solution. === There is no build.properties.sample file in the src distro. If you are providing a build.xml then a build.properties.sample is very useful. === There is slightly odd indenting in the second-to-last line of README.txt. And some slightly odd indenting in RELEASE-NOTES.txt too. It's probably because there are tabs in the files, and I bet you have tabwidth set to 4 on your machine. === Running "maven" in the src dir with java1.5 results in: javac: target release 1.1 conflicts with default source release 1.5 When you have maven.target.compile=1.1 in project.properties you also need maven.target.source=1.2 to avoid this problem. === Maven reports this when run: java:jar: [echo] java:jar is deprecated and will be removed. Please use jar:jar This can be fixed by updating maven.xml: should be unless there's something I don't know === Binary tarball The docs directory contains all the Maven reports, including the "test-xref" and stuff. This is a very large volume of data that almost nobody will want. I suggest removing this from the binary download. See maven.xml in commons-digester for one way to solve this. === other The src distro builds fine with Java1.5 on Linux (debian 3.1). Unfortunately, there are ?? unit test failures when using java 1.3.1: TEST org.apache.commons.betwixt.strategy.TestConversionFlavour FAILED TEST org.apache.commons.betwixt.schema.TestSchemaGeneration FAILED TEST org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping FAILED TEST org.apache.commons.betwixt.io.read.TestMaps FAILED TEST org.apache.commons.betwixt.recursion.TestSharedIDGeneration FAILED TEST org.apache.commons.betwixt.derived.TestWriteClass FAILED They look like real failures; some of the output is shown below. === Testcase: testWrite(org.apache.commons.betwixt.strategy.TestConversionFlavour): FAILED (Unequal node names) expected: but was: junit.framework.ComparisonFailure: (Unequal node names) expected: but was: at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:214) at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:312) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphic(XmlTestCase.java:175) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(XmlTestCase.java:128) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(XmlTestCase.java:105) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(XmlTestCase.java:96) at org.apache.commons.betwixt.strategy.TestConversionFlavour.testWrite(TestConversionFlavour.java:108) === Testcase: testOrderLineBean(org.apache.commons.betwixt.schema.TestSchemaGeneration): FAILED (Unequal attribute values) expected: but was: junit.framework.ComparisonFailure: (Unequal attribute values) expected: but was: at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:269) at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:312) at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:312) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphic(XmlTestCase.java:175) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(XmlTestCase.java:128) at org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(XmlTestCase.java:105) at org.apache.commons.betwixt.schema.TestSchemaGeneration.testOrderLineBean(TestSchemaGeneration.java:151) Testcase: testOrder(org.apache.commons.betwixt.schema.TestSchemaGeneration): FAILED (Unequal attribute values) expected: but was:<1> junit.framework.ComparisonFailure: (Unequal attribute values) expected: but was:<1> at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:269) at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:312) at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.java:312) at org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase
Re: [ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
On Mon, 2005-06-06 at 22:35 +0100, robert burrell donkin wrote: > The first public release candidate (RC3) for Betwixt 0.6.1 is now > available for download: > http://people.apache.org/~rdonkin/commons-betwixt/. Please check and > report any problems ASAP. > Hi Robert, Here's some stuff re the site. Many of these items are just minor typos, but I figured I may as well pass on stuff once I'd spotted it. I don't mean to imply that all of this needs fixing for 1.6.1! === The nightly builds link at the bottom of the welcome page is broken. === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/examples#simple-example "it's" --> its (possessive has no apostrophe). === In the FAQ: This entry has a grammar mistake: How can I stop Betwixt generating ID attribute values for my beans? Perhaps which --> for?? Also the entry titled In what forms can Betwixt output the xml? is perhaps out-of-date? SAXBeanWriter appears to be included in this release... And perhaps this entry is out-of-date? How can I make my extra digestion Rules work with Betwixt? === The SVN link only goes to the viewcvs link. I suggest also having a link to the "raw" URL for subversion. This is much more helpful for locating the string a user needs to pass to the subversion client app to do a checkout. The raw url is present, buried under Project Documentation | Project Info | Source Repository but that isn't very obvious... === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/binding.html XMLIntrotrospector --> XMLIntrospector preformance --> performance === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/derived.html A derived bean is one which runtime class --> "whose runtime class"? === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/writing.html implementating --> implementing and there appears to be something wrong with this statement: Using .betwixt files with DynaBeans is not yet supported and special behaviour of DynaBeans can be overridden by specifying a .betwixt file. gaurantee --> guarantee === Navbar: Menu item "Outputing The Results" --> "Outputting The Results"? Entry "Reading Beans(Advanced)" appears to be in bold for some reason === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/output.html Outputing --> Outputting "SAXBeanWriter push results" --> ".. pushes results" === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/integration.html Cocooon has a few tooo many "o" characters === http://people.apache.org/~rdonkin/commons-betwixt/site/guide/tutorial.html ammendments --> amendments === Dependencies: The bottom of the "tasks" page has * Upgraded commons-beanutils to 1.6.1. * Upgraded commons-digester to 1.5. but the official Maven dependencies are beanutils-1.7 and digester-1.6 respectively. === Maven reports: I would suggest disabling this report. Firstly, a log of the last 30 days isn't of much use. And secondly, due to the import into SVN of back-dated CVS changes, date-based selection on the apache subversion repository is broken, so the report is not just useless but actively WRONG. I suggest that "Developer Activity" and "File Activity" reports are also useless, and (if based on SVN date selection) also wrong. There are 28 warnings in the javadoc warnings report. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT][Betwixt] Betwixt Release 0.6.1 RC3 Available
The first public release candidate (RC3) for Betwixt 0.6.1 is now available for download: http://people.apache.org/~rdonkin/commons-betwixt/. Please check and report any problems ASAP. - robert signature.asc Description: This is a digitally signed message part
