Re: JEUT Champion Recruitment
On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to create a test class that extends a specific JEUT test class and all the work is done for you. The framework uses the annotations discovered via reflection API or the XML files (orm.xml). Do you understand the goal of JEUT? 2008/5/15, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, I think it would really help if you started developing in the open using one of the free open source sites. This would provide the project history to a potential Champion, including access to the source code and general feel of whether you are really interested in building community around your code. On a technical note, what exactly does this framework test? Is this regression testing (i.e. checking that the ORM schema matches the actual DB schema), or is there a value beyond that? We had a similar framework submitted to the Cayenne project some time back, and I could never understand what exactly is being tested. Andrus On May 15, 2008, at 9:57 AM, Alexis Willemyns wrote: Hello all, I was a little bit hesitant before posting this project proposition. But let's go! I hope that this attempt will be a success. JEUT stands for JPA Entity Unit Test and is currently in development. So there is no public website and the code is ended up to 70%. JEUT is a testing framework for JPA entities and its main goal is to automate the test of entities without the need to write long and boring home tests. The mission is to provide a framework which is able to test the matching between entities using annotations and/or xml descriptors and the real database. A framework 100% compliant with all the existing annotations in JPA, for the current version 1 (and the future version 2... in the future). JEUT analyzes all the annotations and creates instances of entites with random values. It tries to persist these instances via the entity manager and reports the problems if existing. JEUT can be used as an extension of JUnit or TestNG, or maybe all others test frameworks. For the moment, the team is only composed with me, and I have discussed with my self about what is means to become an Apacha project. I am aware what are the conditions, responsabilities and impacts to become an Apache project. I am looking a Champion to go in the proposal phase (if the proposal makes sense) and to build a community around JEUT. Thank you for any feedback and recommendations (and sorry for my english coming from Belgium). I look forward to your responses. Regards, Alexis Willemyns JEUT project founder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to create a test class that extends a specific JEUT test class and all the work is done for you. The framework uses the annotations discovered via reflection API or the XML files (orm.xml). Do you understand the goal of JEUT? 2008/5/15, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, I think it would really help if you started developing in the open using one of the free open source sites. This would provide the project history to a potential Champion, including access to the source code and general feel of whether you are really interested in building community around your code. On a technical note, what exactly does this framework test? Is this regression testing (i.e. checking that the ORM schema matches the actual DB schema), or is there a value beyond that? We had a similar framework submitted to the Cayenne project some time back, and I could never understand what exactly is being tested. Andrus On May 15, 2008, at 9:57 AM, Alexis Willemyns wrote: Hello all, I was a little bit hesitant before posting this project proposition. But let's go! I hope that this attempt will be a success. JEUT stands for JPA Entity Unit Test and is currently in development. So there is no public website and the code is ended up to 70%. JEUT is a testing framework for JPA entities and its main goal is to automate the test of entities without the need to write long and boring home tests. The mission is to provide a framework which is able to test the matching between entities using annotations and/or xml descriptors and the real database. A framework 100% compliant with all the existing annotations in JPA, for the current version 1 (and the future version 2... in the future). JEUT analyzes all the annotations and creates instances of entites with random values. It tries to persist these instances via the entity manager and reports the problems if existing. JEUT can be used as an extension of JUnit or TestNG, or maybe all others test frameworks. For the moment, the team is only composed with me, and I have discussed with my self about what is means to become an Apacha project. I am aware what are the conditions, responsabilities and impacts to become an Apache project. I am looking a Champion to go in the proposal phase (if the proposal makes sense) and to build a community around JEUT. Thank you for any feedback and recommendations (and sorry for my english coming from Belgium). I look forward to your responses. Regards, Alexis Willemyns JEUT project founder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
No I don't think it. The goal is not to test the implementation (Hibernate, Toplink, or another one...) of the JPA specification! Imagine the next case. You have a database engineer, who is for example a Oracle specialist, and you have a backend developper. The db engineer has the responsability to create manually the the db and the associated tables. On another side, the backend developper is responsible of the devolpment of entities (pojos) and he must use the JPA specification. So he will add annotations like @Entity, @Id, @Column, etc... Now the backend developer wants to check that his mapping matches with the work of the db engineer. For example, if he defined a column 'name', he want to ensure that there is a column 'name' defined by the db engineer, that the length is the same, that the unique and nullable factors are the same, and so on... If he want to do that, he must write a unit test, and in this test, persist an instance of the entity, and see if there is an error reported by the JPA implementation. JEUT does the job for you. When you said that it will be good that the framework makes sure that the class has the @Entity annotation, etc,... all these errors will be throwed by the JPA implementation. The goal is not to have an integration test, or to test the JPA implementation, but it's to check the synchonization between the Java pojos (entities) and the physical tables. If the 'name' column is defined as nullable=false via an JPA annotation, we want to be sure that in the table defined by the db engineer, the column is defined with null=false. So for this, in the automated tests of JEUT, an entity with the 'name' field value set to null is persisted and an exception is expected. If there is catched exception (throwed by the persistence implementation), the test is a real success. But if there is no catched exception, it means that the db engineer didn't define the column with null=false, and the test fails! Here is another example. In JPA, you can create date, time and timestamp via @Temporal annotation. If the backend developer defines a column with temporal type as date and the db engineer defines the column with time type, all the information about the day, the month and the year are lost. So JEUT tests the matching for the dates, and will find the previous error of mapping. JEUT is compatible all db server, the framework will use the META-INF/persistence.xml defined in the test source folder in the application of the user. So the user can test with the oracle db, hsqldb, derby, mysql,... It's not easy to explain! Is it more clear? Alexis 2008/5/16, James Carman [EMAIL PROTECTED]: At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to create a test class that extends a specific JEUT test class and all the work is done for you. The framework uses the annotations discovered via reflection API or the XML files (orm.xml). Do you understand the goal of JEUT? 2008/5/15, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, I think it would really help if you started developing in the
Re: JEUT Champion Recruitment
Hi Alexis, On Thu, May 15, 2008 at 3:57 PM, Alexis Willemyns [EMAIL PROTECTED] wrote: ... there is no public website and the code is ended up to 70% Like Andrus, I would suggest that you first put make your code and ideas visible to others using one of the open source hosting sites. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [IP CLEARANCE] Moving OSGi Console from Sling to Felix
Hi all, This clearance has passed. So I continue with moving the OSGi console from Sling to Felix. Thanks and Regards Felix Am Dienstag, den 13.05.2008, 12:48 +0200 schrieb Felix Meschberger: Please check clearance on: https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/felix-osgi-console.xml Thanks Felix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
Hi Alexis, Thanks for clarifying. It matches my earlier understanding - it is a model regression testing tool. I am not saying it is not useful, just wanted to define the terms so that we have an understanding of what JEUT is. Andrus On May 16, 2008, at 6:27 AM, Alexis Willemyns wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to create a test class that extends a specific JEUT test class and all the work is done for you. The framework uses the annotations discovered via reflection API or the XML files (orm.xml). Do you understand the goal of JEUT? 2008/5/15, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, I think it would really help if you started developing in the open using one of the free open source sites. This would provide the project history to a potential Champion, including access to the source code and general feel of whether you are really interested in building community around your code. On a technical note, what exactly does this framework test? Is this regression testing (i.e. checking that the ORM schema matches the actual DB schema), or is there a value beyond that? We had a similar framework submitted to the Cayenne project some time back, and I could never understand what exactly is being tested. Andrus On May 15, 2008, at 9:57 AM, Alexis Willemyns wrote: Hello all, I was a little bit hesitant before posting this project proposition. But let's go! I hope that this attempt will be a success. JEUT stands for JPA Entity Unit Test and is currently in development. So there is no public website and the code is ended up to 70%. JEUT is a testing framework for JPA entities and its main goal is to automate the test of entities without the need to write long and boring home tests. The mission is to provide a framework which is able to test the matching between entities using annotations and/or xml descriptors and the real database. A framework 100% compliant with all the existing annotations in JPA, for the current version 1 (and the future version 2... in the future). JEUT analyzes all the annotations and creates instances of entites with random values. It tries to persist these instances via the entity manager and reports the problems if existing. JEUT can be used as an extension of JUnit or TestNG, or maybe all others test frameworks. For the moment, the team is only composed with me, and I have discussed with my self about what is means to become an Apacha project. I am aware what are the conditions, responsabilities and impacts to become an Apache project. I am looking a Champion to go in the proposal phase (if the proposal makes sense) and to build a community around JEUT. Thank you for any feedback and recommendations (and sorry for my english coming from Belgium). I look forward to your responses. Regards, Alexis Willemyns JEUT project founder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
Yes of course, it's in the planning. But I will put a full version of the JEUT framework on the net. It will be probably a hosting with source forge and the use of Maven. Once done, I will give the url. Alexis 2008/5/16, Bertrand Delacretaz [EMAIL PROTECTED]: Hi Alexis, On Thu, May 15, 2008 at 3:57 PM, Alexis Willemyns [EMAIL PROTECTED] wrote: ... there is no public website and the code is ended up to 70% Like Andrus, I would suggest that you first put make your code and ideas visible to others using one of the open source hosting sites. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
it is a model regression testing tool Yes, but I don't like the word regression. In a first step, it's a checking testing framework, and in a second step, it becomes a regression testing framework in the lifecyle of an application. I am happy that my some examples help you to have a deeper view of the JEUT goals. Thanks for your interest. Alexis 2008/5/16, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, Thanks for clarifying. It matches my earlier understanding - it is a model regression testing tool. I am not saying it is not useful, just wanted to define the terms so that we have an understanding of what JEUT is. Andrus On May 16, 2008, at 6:27 AM, Alexis Willemyns wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to create a test class that extends a specific JEUT test class and all the work is done for you. The framework uses the annotations discovered via reflection API or the XML files (orm.xml). Do you understand the goal of JEUT? 2008/5/15, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, I think it would really help if you started developing in the open using one of the free open source sites. This would provide the project history to a potential Champion, including access to the source code and general feel of whether you are really interested in building community around your code. On a technical note, what exactly does this framework test? Is this regression testing (i.e. checking that the ORM schema matches the actual DB schema), or is there a value beyond that? We had a similar framework submitted to the Cayenne project some time back, and I could never understand what exactly is being tested. Andrus On May 15, 2008, at 9:57 AM, Alexis Willemyns wrote: Hello all, I was a little bit hesitant before posting this project proposition. But let's go! I hope that this attempt will be a success. JEUT stands for JPA Entity Unit Test and is currently in development. So there is no public website and the code is ended up to 70%. JEUT is a testing framework for JPA entities and its main goal is to automate the test of entities without the need to write long and boring home tests. The mission is to provide a framework which is able to test the matching between entities using annotations and/or xml descriptors and the real database. A framework 100% compliant with all the existing annotations in JPA, for the current version 1 (and the future version 2... in the future). JEUT analyzes all the annotations and creates instances of entites with random values. It tries to persist these instances via the entity manager and reports the problems if existing. JEUT can be used as an extension of JUnit or TestNG, or maybe all others test frameworks. For the moment, the team is only composed with me, and I have discussed with my self about what is means to become an Apacha project. I am aware what are the conditions, responsabilities and impacts to become an Apache project. I am looking a Champion to go in the proposal phase (if the proposal makes sense) and to build a community around JEUT. Thank you for any feedback and recommendations (and sorry for my english coming from Belgium). I look forward to your responses. Regards, Alexis Willemyns JEUT project founder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Hama into the Incubator
On Thu, May 15, 2008 at 2:40 AM, Yonik Seeley [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 9:28 PM, Otis Gospodnetic [EMAIL PROTECTED] wrote: +1 for the idea, but you don't have Apache Members there (neither Ian nor Jeff are ASF members, as far as I know). Ian is a member. i really like the idea but i'm pretty uncomfortable about having only one member as mentor. maybe we can find another mentor or two... -robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
This sort of thing should be built into the ORM vendor's implementation. It is with Hibernate. If you set hibernate.hbm2ddl.auto=verify, it will make sure the database is set up correctly based on the mapping settings your application specifies. On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: No I don't think it. The goal is not to test the implementation (Hibernate, Toplink, or another one...) of the JPA specification! Imagine the next case. You have a database engineer, who is for example a Oracle specialist, and you have a backend developper. The db engineer has the responsability to create manually the the db and the associated tables. On another side, the backend developper is responsible of the devolpment of entities (pojos) and he must use the JPA specification. So he will add annotations like @Entity, @Id, @Column, etc... Now the backend developer wants to check that his mapping matches with the work of the db engineer. For example, if he defined a column 'name', he want to ensure that there is a column 'name' defined by the db engineer, that the length is the same, that the unique and nullable factors are the same, and so on... If he want to do that, he must write a unit test, and in this test, persist an instance of the entity, and see if there is an error reported by the JPA implementation. JEUT does the job for you. When you said that it will be good that the framework makes sure that the class has the @Entity annotation, etc,... all these errors will be throwed by the JPA implementation. The goal is not to have an integration test, or to test the JPA implementation, but it's to check the synchonization between the Java pojos (entities) and the physical tables. If the 'name' column is defined as nullable=false via an JPA annotation, we want to be sure that in the table defined by the db engineer, the column is defined with null=false. So for this, in the automated tests of JEUT, an entity with the 'name' field value set to null is persisted and an exception is expected. If there is catched exception (throwed by the persistence implementation), the test is a real success. But if there is no catched exception, it means that the db engineer didn't define the column with null=false, and the test fails! Here is another example. In JPA, you can create date, time and timestamp via @Temporal annotation. If the backend developer defines a column with temporal type as date and the db engineer defines the column with time type, all the information about the day, the month and the year are lost. So JEUT tests the matching for the dates, and will find the previous error of mapping. JEUT is compatible all db server, the framework will use the META-INF/persistence.xml defined in the test source folder in the application of the user. So the user can test with the oracle db, hsqldb, derby, mysql,... It's not easy to explain! Is it more clear? Alexis 2008/5/16, James Carman [EMAIL PROTECTED]: At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to
Re: JEUT Champion Recruitment
So, with the solution of hibernate.hbm2ddl.auto=validate, you don't need to write a unit test? If it's the case, the JEUT framework doesn't have any sense. I will test this solution! 2008/5/16, James Carman [EMAIL PROTECTED]: This sort of thing should be built into the ORM vendor's implementation. It is with Hibernate. If you set hibernate.hbm2ddl.auto=verify, it will make sure the database is set up correctly based on the mapping settings your application specifies. On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: No I don't think it. The goal is not to test the implementation (Hibernate, Toplink, or another one...) of the JPA specification! Imagine the next case. You have a database engineer, who is for example a Oracle specialist, and you have a backend developper. The db engineer has the responsability to create manually the the db and the associated tables. On another side, the backend developper is responsible of the devolpment of entities (pojos) and he must use the JPA specification. So he will add annotations like @Entity, @Id, @Column, etc... Now the backend developer wants to check that his mapping matches with the work of the db engineer. For example, if he defined a column 'name', he want to ensure that there is a column 'name' defined by the db engineer, that the length is the same, that the unique and nullable factors are the same, and so on... If he want to do that, he must write a unit test, and in this test, persist an instance of the entity, and see if there is an error reported by the JPA implementation. JEUT does the job for you. When you said that it will be good that the framework makes sure that the class has the @Entity annotation, etc,... all these errors will be throwed by the JPA implementation. The goal is not to have an integration test, or to test the JPA implementation, but it's to check the synchonization between the Java pojos (entities) and the physical tables. If the 'name' column is defined as nullable=false via an JPA annotation, we want to be sure that in the table defined by the db engineer, the column is defined with null=false. So for this, in the automated tests of JEUT, an entity with the 'name' field value set to null is persisted and an exception is expected. If there is catched exception (throwed by the persistence implementation), the test is a real success. But if there is no catched exception, it means that the db engineer didn't define the column with null=false, and the test fails! Here is another example. In JPA, you can create date, time and timestamp via @Temporal annotation. If the backend developer defines a column with temporal type as date and the db engineer defines the column with time type, all the information about the day, the month and the year are lost. So JEUT tests the matching for the dates, and will find the previous error of mapping. JEUT is compatible all db server, the framework will use the META-INF/persistence.xml defined in the test source folder in the application of the user. So the user can test with the oracle db, hsqldb, derby, mysql,... It's not easy to explain! Is it more clear? Alexis 2008/5/16, James Carman [EMAIL PROTECTED]: At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the
Re: JEUT Champion Recruitment
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File(target/sql/schema.sql);
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
So, with the solution of hibernate.hbm2ddl.auto=validate, you don't need
to write a unit test? If it's the case, the JEUT framework doesn't have any
sense. I will test this solution!
2008/5/16, James Carman [EMAIL PROTECTED]:
This sort of thing should be built into the ORM vendor's
implementation. It is with Hibernate. If you set
hibernate.hbm2ddl.auto=verify, it will make sure the database is set
up correctly based on the mapping settings your application specifies.
On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
No I don't think it. The goal is not to test the implementation
(Hibernate,
Toplink, or another one...) of the JPA specification!
Imagine the next case. You have a database engineer, who is for example a
Oracle specialist, and you have a backend developper. The db engineer has
the responsability to create manually the the db and the associated
tables.
On another side, the backend developper is responsible of the devolpment
of
entities (pojos) and he must use the JPA specification. So he will add
annotations like @Entity, @Id, @Column, etc...
Now the backend developer wants to check that his mapping matches with
the
work of the db engineer. For example, if he defined a column 'name', he
want
to ensure that there is a column 'name' defined by the db engineer, that
the
length is the same, that the unique and nullable factors are the same,
and
so on... If he want to do that, he must write a unit test, and in this
test,
persist an instance of the entity, and see if there is an error reported
by
the JPA implementation. JEUT does the job for you.
When you said that it will be good that the framework makes sure that the
class has the @Entity annotation, etc,... all these errors will be
throwed
by the JPA implementation. The goal is not to have an integration test,
or
to test the JPA implementation, but it's to check the synchonization
between
the Java pojos (entities) and the physical tables. If the 'name' column
is
defined as nullable=false via an JPA annotation, we want to be sure that
in
the table defined by the db engineer, the column is defined with
null=false.
So for this, in the automated tests of JEUT, an entity with the 'name'
field
value set to null is persisted and an exception is expected. If there is
catched exception (throwed by the persistence implementation), the test
is a
real success. But if there is no catched exception, it means that the db
engineer didn't define the column with null=false, and the test fails!
Here is another example. In JPA, you can create date, time and timestamp
via
@Temporal annotation. If the backend developer defines a column with
temporal type as date and the db engineer defines the column with time
type,
all the information about the day, the month and the year are lost. So
JEUT
tests the matching for the dates, and will find the previous error of
mapping.
JEUT is compatible all db server, the framework will use the
META-INF/persistence.xml defined in the test source folder in the
application of the user. So the user can test with the oracle db, hsqldb,
derby, mysql,...
It's not easy to explain!
Is it more clear?
Alexis
2008/5/16, James Carman [EMAIL PROTECTED]:
At that point, aren't you just testing that the ORM implementation
works? Wouldn't it be better to make unit tests that test the
values of the annotations at runtime? Stuff like:
1. Make sure class X has the @Entity annotation.
2. Make sure its id property has the @Id annotation.
3. Make sure the getter for property foo has the @Basic annotation
marking it as required.
4. Make sure the getter for property foo has the @Column annotation
making it saved in the FOO column with length 255
If you want to test that the data is actually getting to the database,
I'd argue that isn't really a unit test, but an integration test.
Now to test queries you write, you'd probably want to use something
Re: JEUT Champion Recruitment
BTW, if that turns to be the case, you can still collaborate with OpenJPA and Cayenne projects @Apache to provide similar functionality. Andrus On May 16, 2008, at 9:30 AM, Alexis Willemyns wrote: So, with the solution of hibernate.hbm2ddl.auto=validate, you don't need to write a unit test? If it's the case, the JEUT framework doesn't have any sense. I will test this solution! 2008/5/16, James Carman [EMAIL PROTECTED]: This sort of thing should be built into the ORM vendor's implementation. It is with Hibernate. If you set hibernate.hbm2ddl.auto=verify, it will make sure the database is set up correctly based on the mapping settings your application specifies. On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: No I don't think it. The goal is not to test the implementation (Hibernate, Toplink, or another one...) of the JPA specification! Imagine the next case. You have a database engineer, who is for example a Oracle specialist, and you have a backend developper. The db engineer has the responsability to create manually the the db and the associated tables. On another side, the backend developper is responsible of the devolpment of entities (pojos) and he must use the JPA specification. So he will add annotations like @Entity, @Id, @Column, etc... Now the backend developer wants to check that his mapping matches with the work of the db engineer. For example, if he defined a column 'name', he want to ensure that there is a column 'name' defined by the db engineer, that the length is the same, that the unique and nullable factors are the same, and so on... If he want to do that, he must write a unit test, and in this test, persist an instance of the entity, and see if there is an error reported by the JPA implementation. JEUT does the job for you. When you said that it will be good that the framework makes sure that the class has the @Entity annotation, etc,... all these errors will be throwed by the JPA implementation. The goal is not to have an integration test, or to test the JPA implementation, but it's to check the synchonization between the Java pojos (entities) and the physical tables. If the 'name' column is defined as nullable=false via an JPA annotation, we want to be sure that in the table defined by the db engineer, the column is defined with null=false. So for this, in the automated tests of JEUT, an entity with the 'name' field value set to null is persisted and an exception is expected. If there is catched exception (throwed by the persistence implementation), the test is a real success. But if there is no catched exception, it means that the db engineer didn't define the column with null=false, and the test fails! Here is another example. In JPA, you can create date, time and timestamp via @Temporal annotation. If the backend developer defines a column with temporal type as date and the db engineer defines the column with time type, all the information about the day, the month and the year are lost. So JEUT tests the matching for the dates, and will find the previous error of mapping. JEUT is compatible all db server, the framework will use the META-INF/persistence.xml defined in the test source folder in the application of the user. So the user can test with the oracle db, hsqldb, derby, mysql,... It's not easy to explain! Is it more clear? Alexis 2008/5/16, James Carman [EMAIL PROTECTED]: At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your
Re: JEUT Champion Recruitment
Yes it seems to work perfectly. Is there an equivalent for Toplink of
Oracle?
2008/5/16, James Carman [EMAIL PROTECTED]:
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File(target/sql/schema.sql);
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
So, with the solution of hibernate.hbm2ddl.auto=validate, you don't
need
to write a unit test? If it's the case, the JEUT framework doesn't have
any
sense. I will test this solution!
2008/5/16, James Carman [EMAIL PROTECTED]:
This sort of thing should be built into the ORM vendor's
implementation. It is with Hibernate. If you set
hibernate.hbm2ddl.auto=verify, it will make sure the database is set
up correctly based on the mapping settings your application specifies.
On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
No I don't think it. The goal is not to test the implementation
(Hibernate,
Toplink, or another one...) of the JPA specification!
Imagine the next case. You have a database engineer, who is for
example a
Oracle specialist, and you have a backend developper. The db engineer
has
the responsability to create manually the the db and the associated
tables.
On another side, the backend developper is responsible of the
devolpment
of
entities (pojos) and he must use the JPA specification. So he will add
annotations like @Entity, @Id, @Column, etc...
Now the backend developer wants to check that his mapping matches with
the
work of the db engineer. For example, if he defined a column 'name',
he
want
to ensure that there is a column 'name' defined by the db engineer,
that
the
length is the same, that the unique and nullable factors are the same,
and
so on... If he want to do that, he must write a unit test, and in this
test,
persist an instance of the entity, and see if there is an error
reported
by
the JPA implementation. JEUT does the job for you.
When you said that it will be good that the framework makes sure that
the
class has the @Entity annotation, etc,... all these errors will be
throwed
by the JPA implementation. The goal is not to have an integration
test,
or
to test the JPA implementation, but it's to check the synchonization
between
the Java pojos (entities) and the physical tables. If the 'name'
column
is
defined as nullable=false via an JPA annotation, we want to be sure
that
in
the table defined by the db engineer, the column is defined with
null=false.
So for this, in the automated tests of JEUT, an entity with the 'name'
field
value set to null is persisted and an exception is expected. If there
is
catched exception (throwed by the persistence implementation), the
test
is a
real success. But if there is no catched exception, it means that the
db
engineer didn't define the column with null=false, and the test fails!
Here is another example. In JPA, you can create date, time and
timestamp
via
@Temporal annotation. If the backend developer defines a column with
temporal type as date and the db engineer defines the column with time
type,
all the information about the day, the month and the year are lost. So
JEUT
tests the matching for the dates, and will find the previous error of
mapping.
JEUT is compatible all db server, the framework will use the
META-INF/persistence.xml defined in the test source folder in the
application of the user. So the user can test with the oracle db,
hsqldb,
derby, mysql,...
It's not easy to explain!
Is it more clear?
Alexis
2008/5/16, James Carman [EMAIL PROTECTED]:
At that point, aren't you just testing that the ORM implementation
works? Wouldn't it be better to make unit tests that test the
values of the annotations at runtime? Stuff like:
1. Make sure class X has the @Entity annotation.
2. Make sure its id property has the @Id annotation.
3. Make sure the getter for property foo has the @Basic annotation
marking it as required.
4. Make sure the getter for property foo has the @Column
annotation
making it saved
Re: JEUT Champion Recruitment
I do not use Toplink, so I wouldn't be a good person to answer that
question. I'm glad the Hibernate stuff could help you, though. We've
found that to be a lifesaver in our project.
On Fri, May 16, 2008 at 9:45 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
Yes it seems to work perfectly. Is there an equivalent for Toplink of
Oracle?
2008/5/16, James Carman [EMAIL PROTECTED]:
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File(target/sql/schema.sql);
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
So, with the solution of hibernate.hbm2ddl.auto=validate, you don't
need
to write a unit test? If it's the case, the JEUT framework doesn't have
any
sense. I will test this solution!
2008/5/16, James Carman [EMAIL PROTECTED]:
This sort of thing should be built into the ORM vendor's
implementation. It is with Hibernate. If you set
hibernate.hbm2ddl.auto=verify, it will make sure the database is set
up correctly based on the mapping settings your application specifies.
On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
No I don't think it. The goal is not to test the implementation
(Hibernate,
Toplink, or another one...) of the JPA specification!
Imagine the next case. You have a database engineer, who is for
example a
Oracle specialist, and you have a backend developper. The db engineer
has
the responsability to create manually the the db and the associated
tables.
On another side, the backend developper is responsible of the
devolpment
of
entities (pojos) and he must use the JPA specification. So he will add
annotations like @Entity, @Id, @Column, etc...
Now the backend developer wants to check that his mapping matches with
the
work of the db engineer. For example, if he defined a column 'name',
he
want
to ensure that there is a column 'name' defined by the db engineer,
that
the
length is the same, that the unique and nullable factors are the same,
and
so on... If he want to do that, he must write a unit test, and in this
test,
persist an instance of the entity, and see if there is an error
reported
by
the JPA implementation. JEUT does the job for you.
When you said that it will be good that the framework makes sure that
the
class has the @Entity annotation, etc,... all these errors will be
throwed
by the JPA implementation. The goal is not to have an integration
test,
or
to test the JPA implementation, but it's to check the synchonization
between
the Java pojos (entities) and the physical tables. If the 'name'
column
is
defined as nullable=false via an JPA annotation, we want to be sure
that
in
the table defined by the db engineer, the column is defined with
null=false.
So for this, in the automated tests of JEUT, an entity with the 'name'
field
value set to null is persisted and an exception is expected. If there
is
catched exception (throwed by the persistence implementation), the
test
is a
real success. But if there is no catched exception, it means that the
db
engineer didn't define the column with null=false, and the test fails!
Here is another example. In JPA, you can create date, time and
timestamp
via
@Temporal annotation. If the backend developer defines a column with
temporal type as date and the db engineer defines the column with time
type,
all the information about the day, the month and the year are lost. So
JEUT
tests the matching for the dates, and will find the previous error of
mapping.
JEUT is compatible all db server, the framework will use the
META-INF/persistence.xml defined in the test source folder in the
application of the user. So the user can test with the oracle db,
hsqldb,
derby, mysql,...
It's not easy to explain!
Is it more clear?
Alexis
2008/5/16, James Carman [EMAIL PROTECTED]:
At that point, aren't you just testing that the ORM implementation
works? Wouldn't it be better to make unit tests that test the
values of the annotations at runtime? Stuff like:
1. Make sure class X has the
Re: [VOTE] Apache Tuscany Graduation as TLP
+1 Bill ant elder wrote: After 29 months in the incubator, 19 releases, 25 new committers, and tons of emails the Apache Tuscany community (with support from our mentors) again feels that we are ready to graduate to an official top level project at Apache as indicated by the community vote recorded at: http://apache.markmail.org/message/lss5jhjxail7m67r We would like the resolution below to be presented to the board for consideration at the next possible board meeting. For additional information, the Tuscany status file is here: https://svn.apache.org/repos/asf/incubator/tuscany/STATUS Thanks in advance for your time and consideration. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apache Tuscany Graduation as TLP
+1 Carl. ant elder wrote: After 29 months in the incubator, 19 releases, 25 new committers, and tons of emails the Apache Tuscany community (with support from our mentors) again feels that we are ready to graduate to an official top level project at Apache as indicated by the community vote recorded at: http://apache.markmail.org/message/lss5jhjxail7m67r We would like the resolution below to be presented to the board for consideration at the next possible board meeting. For additional information, the Tuscany status file is here: https://svn.apache.org/repos/asf/incubator/tuscany/STATUS Thanks in advance for your time and consideration. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Account Request - Ted Ross- Qpid (incubating)
Dear root, Please create an id for Ted Ross on the Qpid project under Incubation. Preferred userid: tross Full name: Ted Ross Forwarding email address: [EMAIL PROTECTED] Requested Karma for: qpid ICLA is on file. Votes:(17: +1 which includes 3 bindings, and no -1 or 0.) Vote conducted on [EMAIL PROTECTED] and completed on [EMAIL PROTECTED] kind regards Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
What a good idea! I am really interested by the persistence layer. It would be a great pleasure to work on the Cayenne project. If you desire, we can speak about that by private email. Contact me at [EMAIL PROTECTED] 2008/5/16 Andrus Adamchik [EMAIL PROTECTED]: BTW, if that turns to be the case, you can still collaborate with OpenJPA and Cayenne projects @Apache to provide similar functionality. Andrus On May 16, 2008, at 9:30 AM, Alexis Willemyns wrote: So, with the solution of hibernate.hbm2ddl.auto=validate, you don't need to write a unit test? If it's the case, the JEUT framework doesn't have any sense. I will test this solution! 2008/5/16, James Carman [EMAIL PROTECTED]: This sort of thing should be built into the ORM vendor's implementation. It is with Hibernate. If you set hibernate.hbm2ddl.auto=verify, it will make sure the database is set up correctly based on the mapping settings your application specifies. On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: No I don't think it. The goal is not to test the implementation (Hibernate, Toplink, or another one...) of the JPA specification! Imagine the next case. You have a database engineer, who is for example a Oracle specialist, and you have a backend developper. The db engineer has the responsability to create manually the the db and the associated tables. On another side, the backend developper is responsible of the devolpment of entities (pojos) and he must use the JPA specification. So he will add annotations like @Entity, @Id, @Column, etc... Now the backend developer wants to check that his mapping matches with the work of the db engineer. For example, if he defined a column 'name', he want to ensure that there is a column 'name' defined by the db engineer, that the length is the same, that the unique and nullable factors are the same, and so on... If he want to do that, he must write a unit test, and in this test, persist an instance of the entity, and see if there is an error reported by the JPA implementation. JEUT does the job for you. When you said that it will be good that the framework makes sure that the class has the @Entity annotation, etc,... all these errors will be throwed by the JPA implementation. The goal is not to have an integration test, or to test the JPA implementation, but it's to check the synchonization between the Java pojos (entities) and the physical tables. If the 'name' column is defined as nullable=false via an JPA annotation, we want to be sure that in the table defined by the db engineer, the column is defined with null=false. So for this, in the automated tests of JEUT, an entity with the 'name' field value set to null is persisted and an exception is expected. If there is catched exception (throwed by the persistence implementation), the test is a real success. But if there is no catched exception, it means that the db engineer didn't define the column with null=false, and the test fails! Here is another example. In JPA, you can create date, time and timestamp via @Temporal annotation. If the backend developer defines a column with temporal type as date and the db engineer defines the column with time type, all the information about the day, the month and the year are lost. So JEUT tests the matching for the dates, and will find the previous error of mapping. JEUT is compatible all db server, the framework will use the META-INF/persistence.xml defined in the test source folder in the application of the user. So the user can test with the oracle db, hsqldb, derby, mysql,... It's not easy to explain! Is it more clear? Alexis 2008/5/16, James Carman [EMAIL PROTECTED]: At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example
Re: [VOTE] Accept Hama into the Incubator
i really like the idea but i'm pretty uncomfortable about having only one member as mentor. maybe we can find another mentor or two... Right you're, We would leave the vote open a bit longer and continue the discussion until we have enough votes and mentors. -Edward On Fri, May 16, 2008 at 9:58 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 2:40 AM, Yonik Seeley [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 9:28 PM, Otis Gospodnetic [EMAIL PROTECTED] wrote: +1 for the idea, but you don't have Apache Members there (neither Ian nor Jeff are ASF members, as far as I know). Ian is a member. i really like the idea but i'm pretty uncomfortable about having only one member as mentor. maybe we can find another mentor or two... -robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- B. Regards, Edward J. Yoon, http://blog.udanax.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
