Re: [Hibernate] questions regarding development setup
Is there some actualproblem we are trying to solve here? Because if there is, no-one has pointed it out yet. The point of the failing tests is to remind and nag us to get them fixed. If we hide the failures we remove that incentive. There has been a bunch of handwaving about how this could theoretically be a problem for continuous integration ... except that weare doing continuous integration and itis not causing anyproblems! It seems there are some people here who have reada couple of booksby Kent Beckand think that their job as a software developer is to enforce their Holy Perfect Process on everyone. That's perfectly fine, but we are practical people running an actual serious software project here, and we don't have time for trying to impress people by how aGiLe we are. Thanks for your input, this is the end of the thread. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik BertelsenSent: Sunday, June 11, 2006 12:35 PMTo: Max AndersenCc: hibernate-devel@lists.sourceforge.netSubject: Re: [Hibernate] questions regarding development setup 2006/6/11, Max Rydahl Andersen [EMAIL PROTECTED]: as i mentioned at the bug we could actually implement this by doing acustom impl of HibernateTestCase.runTest()/max Hi all,what about a version of runTest() that silently accepts test failures for tests that are expected to fail and report them as 'failures' if they suddenly start to succeed. This will have the intended result that a test run is silent if everything works out as expected and if a test that is expected to fail suddenly succeeds, it will show up in the test report.If the success of the test was intentional because the problem was solved, the test should of course be changed to a normal non-failure-expected test. If the success was an unintentional consequence of some code change, then the developer can investigate whether the problem was really solved or just disguised and possibly alter the test. - Erik ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
You're right. We should never have "expected failure" type tests in a test suite so that we can get back to things we know we want to fix. That is so crazy; what are we thinking here…ha ha ha :) Of course you should test non-happy path / expected failure / exception condition. But c reating failing test to be patched who-knows-when... Continuous integration server fails every time but it's fine (are you using CI?). All the time you have to check if tests that fail are the one that suppose to fail or not (steals time / error prone)... How can developer know if the codebase in svn is not broken? - only by comparing list of failures with list of expected failures. And you guys have to make this comparison every time you evaluate someone's patch... And as for a projects choice of how to define tests impacting that projects credibility in *your projects* mind… Well, lets just say I now have a severe impacting regarding your project's credibility ;) ha ha :) let's defend my credibility ;p - Years ago I tried approach of committing into source control deliberately failing test cases corresponding to particular log in issue management tool... It just doesn't work in CI based environment. I see no reason of creating only testcase (w/o fix) since you have the information about the bug in jira. You defer the bugfix to vague future... when something changes regarding the bug on jira you have to update testcase... Bug should be covered with test, then fixed, then checked into svn... Does having failing testcases of known bugs is a reason to be proud? Perhaps you are encouraging contributors to fix bugs by creating failing testcase's? BTW is it working?You may have process of estimation/analysis of a jira log with the output of failing testcase. If it's working for you - that's great. But in my opinion developer should have a clear understanding of stable code base which is green color on junit progress bar. And the development should be red - green - refactor not red - red - refactor. And do you rather want us to remove tests for known issues ?I'd prefer refactor to separate source folder, perhaps not taking part in main build and in future not checking into svn without an actual bugfix :) Thanks,Szczepan FaberOn 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) I've already created patch with couple testcases using same package layout on purpose.ok. No reason to change what just works. reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?)well, it has never been an issue since we have more than enough tests thatdoes this, so again it just works. Anyway I will just contribute a patch and let's see what you say... ok. PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues.unreasonable test packaging ? Nothing *prevents* you from using another layout - andsince our testsuite contains considerable more test than I've seencompared to otherapplications/frameworks it doesn't seem to be an issue in real life vs.theoretical rants.And do you rather want us to remove tests for known issues ? That sounds like you wantus to hide the fact we know some part has a bug/issue ? how is that forcredibility ?/max Thanks, Szczepan On 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? No reason to change what just works. The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) /max Thanks, SzczepanOn 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote:1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods.2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL
Re: [Hibernate] questions regarding development setup
Its more a limitation of the testing environment than project structure. One should be able to annotate known tests as failing at either the test or ci layer to achieve a simple boolean overall result as to whether the testsuite is in an expected state. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max Rydahl Andersen Sent: Friday, June 09, 2006 10:03 AM To: Szczepan Faber Cc: hibernate-devel@lists.sourceforge.net Subject: Re: [Hibernate] questions regarding development setup The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) I've already created patch with couple testcases using same package layout on purpose. ok. No reason to change what just works. reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?) well, it has never been an issue since we have more than enough tests that does this, so again it just works. Anyway I will just contribute a patch and let's see what you say... ok. PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues. unreasonable test packaging ? Nothing *prevents* you from using another layout - and since our testsuite contains considerable more test than I've seen compared to other applications/frameworks it doesn't seem to be an issue in real life vs. theoretical rants. And do you rather want us to remove tests for known issues ? That sounds like you want us to hide the fact we know some part has a bug/issue ? how is that for credibility ? /max ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
Title: RE: [Hibernate] questions regarding development setup Yes, but no such thing exist AFAIK. That is why we introduced this failureExpected notion. /max -Original Message- From: Scott M Stark Sent: Sat 10-06-2006 17:32 To: Max Andersen; Szczepan Faber Cc: hibernate-devel@lists.sourceforge.net Subject: RE: [Hibernate] questions regarding development setup Its more a limitation of the testing environment than project structure. One should be able to annotate known tests as failing at either the test or ci layer to achieve a simple boolean overall result as to whether the testsuite is in an expected state. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Max Rydahl Andersen Sent: Friday, June 09, 2006 10:03 AM To: Szczepan Faber Cc: hibernate-devel@lists.sourceforge.net Subject: Re: [Hibernate] questions regarding development setup The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) I've already created patch with couple testcases using same package layout on purpose. ok. No reason to change what just works. reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?) well, it has never been an issue since we have more than enough tests that does this, so again it just works. Anyway I will just contribute a patch and let's see what you say... ok. PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues. unreasonable test packaging ? Nothing *prevents* you from using another layout - and since our testsuite contains considerable more test than I've seen compared to other applications/frameworks it doesn't seem to be an issue in real life vs. theoretical rants. And do you rather want us to remove tests for known issues ? That sounds like you want us to hide the fact we know some part has a bug/issue ? how is that for credibility ? /max ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
You're right. We should never have expected failure type tests in a test suite so that we can get back to things we know we want to fix. That is so crazy; what are we thinking here… How can developer know if the codebase in svn is not broken? - only by comparing list of failures with list of expected failures. And you guys have to make this comparison every time you evaluate someone's patch... It is not optimal, but it is quite easy to see if a method not called failureExpected is failing. We know it is not optimal, but it is better than removing those tests. to particular log in issue management tool... It just doesn't work in CI based environment. I see no reason of creating only testcase (w/o fix) since you have the information about the bug in jira. You defer the bugfix to vague future... when something changes regarding the bug on jira you have to update testcase... Bug should be covered with test, then fixed, then checked into svn... Does having failing testcases of known bugs is a reason to be proud? Having the tests only in jira make them being deferred even longer. You may have process of estimation/analysis of a jira log with the output of failing testcase. If it's working for you - that's great. But in my opinion developer should have a clear understanding of stable code base which is green color on junit progress bar. And the development should be red - green - refactor not red - red - refactor. Again, we prefer to have the failureExpected then none at all. And do you rather want us to remove tests for known issues ? I'd prefer refactor to separate source folder, perhaps not taking part in main build and in future not checking into svn without an actual bugfix :) If you looked at the tests you would see why they are not in seperate classes/folders would add very redundant testcode that is even worse to maintain. Again, as Scott so correctly pointed out; it is a limitation of the unittest framework we are trying to cope with. /max Thanks, Szczepan Faber On 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) I've already created patch with couple testcases using same package layout on purpose. ok. No reason to change what just works. reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?) well, it has never been an issue since we have more than enough tests that does this, so again it just works. Anyway I will just contribute a patch and let's see what you say... ok. PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues. unreasonable test packaging ? Nothing *prevents* you from using another layout - and since our testsuite contains considerable more test than I've seen compared to other applications/frameworks it doesn't seem to be an issue in real life vs. theoretical rants. And do you rather want us to remove tests for known issues ? That sounds like you want us to hide the fact we know some part has a bug/issue ? how is that for credibility ? /max Thanks, Szczepan On 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? No reason to change what just works. The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) /max Thanks, Szczepan On 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: 1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] -- -- Max Rydahl
Re: [Hibernate] questions regarding development setup
b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? No reason to change what just works. The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) /max Thanks, Szczepan On 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: 1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;)I've already created patch with couple testcases using same package layout on purpose. No reason to change what just works.reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?)Anyway I will just contribute a patch and let's see what you say... PSWhatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues.Thanks,Szczepan On 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? No reason to change what just works.The day you write a (needed and usefull!) unittest that is not possiblein our current setup then lets talk ;)/max Thanks, Szczepan On 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: 1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] Max Rydahl Andersencallto://max.rydahl.andersenHibernate[EMAIL PROTECTED] http://hibernate.orgJBoss Inc [EMAIL PROTECTED] ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
On Jun 9, 2006, at 6:07 PM, Szczepan Faber wrote: Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. This is the most bizarre thing I've heard in quite a while... ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
Youre right. We should never have expected failure type tests in a test suite so that we can get back to things we know we want to fix. That is so crazy; what are we thinking here And as for a projects choice of how to define tests impacting that projects credibility in *your projects* mind Well, lets just say I now have a severe impacting regarding your projects credibility ;) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szczepan Faber Sent: Friday, June 09, 2006 11:08 AM To: Max Andersen Cc: hibernate-devel@lists.sourceforge.net Subject: Re: [Hibernate] questions regarding development setup The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) I've already created patch with couple testcases using same package layout on purpose. No reason to change what just works. reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?) Anyway I will just contribute a patch and let's see what you say... PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues. Thanks, Szczepan On 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? No reason to change what just works. The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) /max Thanks, Szczepan On 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: 1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) I've already created patch with couple testcases using same package layout on purpose. ok. No reason to change what just works. reasons: every time the developer cannot unit test non-public method / class w/o public constructor. (every day :) ?) well, it has never been an issue since we have more than enough tests that does this, so again it just works. Anyway I will just contribute a patch and let's see what you say... ok. PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues. unreasonable test packaging ? Nothing *prevents* you from using another layout - and since our testsuite contains considerable more test than I've seen compared to other applications/frameworks it doesn't seem to be an issue in real life vs. theoretical rants. And do you rather want us to remove tests for known issues ? That sounds like you want us to hide the fact we know some part has a bug/issue ? how is that for credibility ? /max Thanks, Szczepan On 6/9/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? No reason to change what just works. The day you write a (needed and usefull!) unittest that is not possible in our current setup then lets talk ;) /max Thanks, Szczepan On 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: 1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
1. Why there are about 10 failing test after getting project from svn? a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue. To make the test pass, fix the bug ;) b) others depend on your db, but for the moment I only have failureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...) Not strange at all and there is no need to have them in the same package. Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
a) ok :)b) But what's the reason of making surprising test subpackage (I've never seen something like that)? You can still have integration/acceptance test cases in 'normal' package or even in different source folder. Unreasonable subpackage makes it hard to write real unit test, you cannot test non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? Thanks,SzczepanOn 6/8/06, Max Rydahl Andersen [EMAIL PROTECTED] wrote: 1. Why there are about 10 failing test after getting project from svn?a) if the method ends in FailureExpected, then it is an expected failure which represents a known bug/issue.To make the test pass, fix the bug ;)b) others depend on your db, but for the moment I only havefailureExpected methods. 2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...)Not strange at all and there is no need to have them in the same package.Alot of our tests is usecase based tests which does not fit 100% into the implmentation layout.Max Rydahl Andersencallto://max.rydahl.andersenHibernate[EMAIL PROTECTED] http://hibernate.orgJBoss Inc[EMAIL PROTECTED] ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
On Jun 9, 2006, at 12:00 AM, Szczepan Faber wrote: Don't you have a refactoring plan to remove test subpackage? No, we don't. Really, tests in a test package are not surprising at all. ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] questions regarding development setup
1. Why there are about 10 failing test after getting project from svn?2. Why do you keep test files in strange org.hibernate.test package? Shouldn't it be same package as sources (e.g. org.hibernate...)Thanks, Szczepan ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
