Community
Participate
Working Groups
Created attachment 87773 [details] JPA Wizard - design document The creation of JPA Entity class now is passing in two steps: 1.Creation of POJO (Java Class) 2.Annotate it via the views of JPA Development Perspectives In our adopted product we are developed a specific wizard, which creates Persistence (JPA) Entities from scratch. If you have interest about such wizard, we could contribute it. I have attached a design document with our proposal. We have implemented a part of the functionality and this document presents our vision for the JPA entity wizard in its final state. So the proposal is open for the discussion / improvements if it is necessary
This looks great. I think this would be a nice enhancement to Dali. Is this something that could potentially be contributed in the 2.0 time-frame? I'll give time for others to comment, but in general, I think this would be very nice to have.
As I have mentioned, the implementation is partial. If we come to an agreement about the final design soon, we will succeed to finish the wizard. In brief: If the discussions finish in the range of M5 (till the middle of February), we will be able to contribute the wizard for M6.
The proposal looks like a nice addition! A couple of notes: 1. It would be good if the wizard followed the Dali approach to showing defaults in the table name drop down (e.g., as in the JPA Details view). 2. The wizard should also support XML mapping. This means that the user would have to select whether to use annotations or XML. If XML then what orm.xml file? If there is no such file then we'd need support for creating the file and if not named "orm.xml" then updating the persistence.xml with the mapping file reference. A bunch of work unfortunately. 3. Entity Field selection should *optionally* be filtered as described in the design doc. We don't want to dictate to the developer the order in which they should define entities. This means that they should be able to create an Entity that has a non-Entity as a field type. If a non-Entity or non-serializable class is selected then Dali validation should produce an error message once the new Entity is saved. The user could optionally be asked if they want to convert the non-Entity class to an Entity (which brings up the issue of whether to use annotations or XML again). --Shaun
About the notes: 1. This would be implemented fast, I think. 2. The support of XML mapping (in dependence of the user preferences) is a good idea. The agreement depends of the efforts needed in this direction. I should ground in support of ORM XML file, in order to comment this feature. Could you direct me to some documentation, API or code snippet for creation (editing) of mapping XML, in order to estimate roughly, please? 3. This sounds reasonable. Actually the filter implementation was nice to have feature in our proposal. So for the first version we could skip it and it could be implemented as feature in the future. A possible solution for this feature is to be switched on via check box. As I saw, that the design have been accepted mostly, I will start the preparation for the contribution, while I知 waiting for additional comments. If such exists, they are welcomed.
Regarding item #2, you could start by taking a look at JpaModel.createOrmXml(IProject). This creates the template orm.xml file when selected during JPA project creation. It doesn't add much content to the orm.xml but it might be enough to get the idea.
Created attachment 92320 [details] new entity wizard The new entity wizard is patched to the plugin org.eclipse.jpt.ui (HEAD)
I attached a patch, which contains the current implementation of new entity wizard in accordance with the discussed document. The wizard is intended to create from the scratch an entity (or mapped superclass) with its fields and to create most fundamental annotations for the generated artifact(s). The creation of the relations between the entities is out of the scope of this wizard. The wizard is implemented in context of Data Model Framework (as DataModelWizard) like other wizards in WTP toolset. In this state the wizard could - create a mapped superclass, add fields to it and annotate the primary key field(s) (if such is set) in accordance with the chosen access type - create an entity and its fields, annotate them in accordance with the chosen access type - annotate the entity with entity name, table name and inheritance annotations in accordance with the settings, chosen from the user - create complex ID via generation of ID class, when more than one field is set as primary key Limitations in the current implementation - EmbeddedId should be checked manually after the creation. The wizard don’t check whether the added field is embedded id class - The field type browse dialog (invoke when entity field is adding) could not be filtered to show persistable types only - There isn’t check whether in the hierarchy there is inheritance strategy set, in order to disallow reset of such - There isn’t check whether in the hierarchy exists primary key chosen, in order to disallow primary key setting The missing checks could be implemented easy, if there are API (utility) methods, which make such checks in the context of the existing JPA model. Could you hint me about similar checks? If there aren’t implemented such methods, I could implement them when I get more familiar with the model. Òhe attached patch wizard don’t support XML mapping . I preferred to attach it in this state, because I delayed with the initial implementation, and the time is short. My goal was to discuss the UI, in order to freeze it and to focus on the generation. I’m working on XML mapping generation now and I will attach the subsequent in the next few days (before the end of the week I hope). Could you take a look at the patch and comment your opinion (remarks) in order to improve the wizard if it is necessary. I case of problems, please notify me in order to take action immediately. BTW: When I prepared the patch, I faced very unpleasant regressions. The controls (especially the buttons) had incorrect behavior. On the first action with them (check/selection) they didn’t behave in the accordance with the expectations. It’s proved that in the M5 driver, I was using, there is regression in synchronization of the data properties with the UI. When I got the source of org.eclipse.wst.common.frameworks.ui in order to debug processing, the problem in the runtime workbench disappears, because the issue has been fixed.
Hello, I知 practically finished the implementation of the wizard, including the support of mapping XML. Unfortunately I faced an invincible obstacle at the end. When the xml is default, I obtain it from OrmArtifactEdit and successfully register the new artifact within. The situation is the same, when the default xml doesn稚 exist, but the name is default (orm.xml). I receive the relevant OrmResource and I proceed in the standard way. The problem appeared, when I tried to create mapping XML with different name. I process in this way: 1.Use known method OrmArtifactEdit.getResource (String fileUri), 2.The method receive ReferencedComponentXMIResourceImpl via getArtifactEditModel ().getResource (URI.createURI (fileURI))) 3.The result object (ReferencedComponentXMIResourceImpl) is intended to be casted to OrmResource (row 95) 4.As result ClassCastException is thrown. I tried different approaches: to create file externally before, or to obtain file via edit model and its resource set (oae.getEditModel ().getResourceSet ().createResource (URI.createURI ("META-INF/orm1.xml"),JptCorePlugin.ORM_XML_CONTENT_TYPE)) but unfortunately every time my attempts failed. Have I made mistake(s) or this is bug in the functionality? Every hint will help me and will allow me to finish with the complete patch for the wizard. The second (not so important question) is what should be the scope, where the alternative XML will be stored. For now I have restricted the place underneath META-INF folder, where is placed persistence.xml. Do you have some proposal for this? I知 waiting for a response. Best Regards, Dimiter
Comments on your patch: Overall, it's looking good, thanks for contributing this! Here are a few things I found while testing it out: 1. In the plugin.xml the category for the JPA Wizard is listed as "org.eclipse.jpt.jpaWizardCategoryName" I had to change it to "org.eclipse.jpt" to match our category id. How did this work for you? 2.When adding new entity fields, the dialog widget labels are backwards. Should be "Type:" on the first widget and "Name:' on the second. 3. In the Entity Table selection, should you be able to choose from existing database tables in your connection? It seems this would be nice to have, could also verify that the default table name exists on the database. Though the target user here might be someone who is creating entities and is then going to generate their tables, maybe someone else has ideas here? 4. We need some way to add the newly created type to the persistence.xml if the user has chosen 'Annotated classes must be listed in persistence.xml'. Whether we do this automatically or with a check box like in entity generation from tables is up for discussion. 5.We now have the ability to convert a Java project to a JPA project. If the user has a non-JPA project selected when they choose to create a new JPA entity we could send them through that wizard first(or the JPA facet wizard if it is already a faceted project). Currently, they just can't select their project from the list of projects on the JPA Entity wizard and it instead populates with the first JPA project found. Responding to a few of your limitations: >>There isn’t check whether in the hierarchy there is inheritance strategy >>set, in order to disallow reset of such The JPA spec allows for changing the inheritance strategy mid-hierarchy, I believe it just says it is not portable. I don't think we should disable the UI in this case. >>There isn’t check whether in the hierarchy exists primary key chosen, in >>order to disallow primary key setting We don't currently have API for checking this. But to point you in the right direction you can user PersistentType.allAttributes() to return all the PersistentAttributes in the hierarchy. And then PersistentAttribute.isIdAttribute() which would return true for id and embedded id mappings. I'm sure Shaun and Neil will have opinions on your wizard, but they probably won't voice them until after EclipseCon!
In response to comment #8, I believe we are still working with the WTP xml/translators guys to support an orm.xml file that is not named orm.xml. Hopefully Paul can give an update on this, he is also at EclipseCon this week
(In reply to comment #9) > 1. In the plugin.xml the category for the JPA Wizard is listed as > "org.eclipse.jpt.jpaWizardCategoryName" > I had to change it to "org.eclipse.jpt" to match our category id. How did this > work for you? I was left the category and icons for the end, but thank you for the hint – I will tune this in my final patch. > 2.When adding new entity fields, the dialog widget labels are backwards. > Should be "Type:" on the first widget and "Name:' on the second. I saw this and it is fixed for the final patch > 3. In the Entity Table selection, should you be able to choose from existing > database tables in your connection? It seems this would be nice to have, could > also verify that the default table name exists on the database. Though the > target user here might be someone who is creating entities and is then going to > generate their tables, maybe someone else has ideas here? As the wizard is designed to create an entity (mapped superclass) from scratch (respectively to generate new table after that), I haven’t included this opportunity. Actually the generation from existing tables is provided from the JPA Tools action “Generate Entities…”, so in my opinion this is not needed feature (doubling), which will overload the wizard. Indeed I’m trying to keep away from unnecessary intricacy, and to provide basic features for the user. However, I could include this on demand, if the opinions are in this direction. May be the better solution here is to implement the proposal of Shaun (Comment #3, p.1) - to showing defaults in the table name drop down (e.g., as in the JPA Details view). > 4. We need some way to add the newly created type to the persistence.xml if the > user has chosen 'Annotated classes must be listed in persistence.xml'. Whether > we do this automatically or with a check box like in entity generation from > tables is up for discussion. Thank you for this point, I will include the generation (depends on the property setting) in the final patch. > 5.We now have the ability to convert a Java project to a JPA project. If the > user has a non-JPA project selected when they choose to create a new JPA entity > we could send them through that wizard first(or the JPA facet wizard if it is > already a faceted project). Currently, they just can't select their project > from the list of projects on the JPA Entity wizard and it instead populates > with the first JPA project found. Actually the wizard is designed for JPA faceted projects only, because I was not aware for this functionality. I will investigate whether I could introduce this functionality easy. Thank you also about the comments of my limitation statements and especially for the hint for ID attributes in the hierarchy. I will wait for the possible comments from Shaun and Neil and in the meantime I will repair the wizard in accordance with this discussion. Could you just inform me when is the deadline for the UI changes? Best Regards
(In reply to comment #11) > > 3. In the Entity Table selection, should you be able to choose from existing > > database tables in your connection? It seems this would be nice to have, > > could also verify that the default table name exists on the database. Though > > the target user here might be someone who is creating entities and is then > > going to generate their tables, maybe someone else has ideas here? > > As the wizard is designed to create an entity (mapped superclass) from > scratch (respectively to generate new table after that), I haven’t included > this opportunity. Actually the generation from existing tables is provided > from the JPA Tools action “Generate Entities…”, so in my opinion this is not > needed feature (doubling), which will overload the wizard. Indeed I’m trying > to keep away from unnecessary intricacy, and to provide basic features for the > user. However, I could include this on demand, if the opinions are in this > direction. > May be the better solution here is to implement the proposal of Shaun (Comment > #3, p.1) - to showing defaults in the table name drop down (e.g., as in the > JPA Details view). I agree with you here, we could really make this a huge wizard if we aren't careful. > > 5.We now have the ability to convert a Java project to a JPA project. If > > the user has a non-JPA project selected when they choose to create a new JPA > > entity we could send them through that wizard first(or the JPA facet wizard > > if it is already a faceted project). Currently, they just can't select > > their project from the list of projects on the JPA Entity wizard and it > > instead populates with the first JPA project found. > > Actually the wizard is designed for JPA faceted projects only, because I was > not aware for this functionality. I will investigate whether I could introduce > this functionality easy. I wouldn't call this a deal-breaker on us committing the patch. It is a bug/feature request that we could fix later. The Java->JPA wizard was checked in very recently. > Could you just inform me when is the deadline for the UI changes? I believe we should try to get this in for M6, so we would need to commit the patch by Wednesday March 26th. Though since this is new functionality and not changes to API I think it's possible we could check it in for M7. I'll let Neil confirm that.
As to the issue of support for "differently named" orm.xml files, this is a huge limitation for us as well. No other consumer of the WTP resource framework has this issue of flexibly named resources, and we are attempting to work this out with them. Please see bug 152461
Created attachment 93156 [details] new entity wizard with mapping XML support The attached patch includes ORM XML mapping support. In addition I have fixed the problems, reported from Karen: 1. I removed Entity wizard in the category org.eclipse.jpt. I have added icons too; unfortunately for the wizard I used the icon of JPA facet wizard, because of the proper size. This icon should be changed with the specific one. 2. Add entity field dialog label are fixed 3. If the property of the project is not set for automatic detection of entities, I register the newly created class into the persistence.xml. It could be changed to the style with check box on demand Unfortunately I didn’t manage to implement the table name field to be combo box with default proposals. I planned to reuse the control as it is realized in the JPA Details view, but the data model wizard doesn’t allow synchronization of such type of combo box. I will search other solution, may be I will implement this myself The biggest limitation in this (almost final) implementation is that the creation (using) of mapping XMLs, different that orm.xml is disabled (because of bug 152461). The relevant control is visible, but I have set it to be disabled for now. The wizard is tested manually pretty well, but I will test it more intensive in the following days, and I will try to cover the code with JUnit tests, where it is possible. I’m waiting for feedback.
Dimiter, The wizard is working pretty well for me, with only one issue to mention. First, after generation, the formatting of the Java file is problematic. When we annotate the Java via the UI, the formatting of the class is undone for a given attribute. This can be reproduced by editing a file (via the UI) after it is created via the wizard. This is pretty annoying, and persists across workbench sessions. Not sure what could be behind this, but I have never seen this behavior in hand created or Entity Gen created Java source. The bigger issue is the matter of IP review. Now that the patch is at the point where it could reasonably be checked in (and the size exceeds what can be checked in without a review), we need to start the IP review process. The chance of this feature making it into 2.0 will be based on the speed of which the review can be performed. We will have to wait and see what happens. I will get an exception approved for this feature to go in after M6, but we won't be able to check it in after M7 is closed. If it doesn't make it into 2.0, we would include it in the next feature release vehicle. So, on that topic, please answer the following questions for me so I can get the IP review ball rolling. 1) Did you write 100% of the code in this contribution? 2) Do you have the right to contribute this code to Eclipse? Also, I noticed that some of the jet template files do not have the EPL notice on them. Is there a way to insert a notice on these files? Legal is going to ask about this, so just getting it out of the way. Thanks Dimiter,
Created attachment 93377 [details] patch with some minor corrections I'm very glad to hear this good news from you. About the IP related question: Yes, I have developed 100% of the code in the patch, and I have permission to contribute the wizard to Dali. For the integrated control “entity table – add/edit entity dialog” (the control from the second page) I have utilized an idea from org.eclipse.jst.j2ee.internal.wizard.StringArrayTableWizardSection, adapting it to my specific model. The algorithm for the implementing of equals() and hashCode() methods in ID class is implemented in accordance with the recommended practice from the book "Effective Java" by Joshua Bloch. This note is added as a comment in the generated class. The lack of comments in JET templates, due to the fact that the comment tags, described in the help link follow, didn’t worked correctly: http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.jet.doc/references/syntax/jetSyntaxComments.xhtml The “commented” texts appeared in the generated templates, broken the generation of artifacts. I will investigate deeper the issue. I saw the formatting issue after the generation. On my side it appears as missing blank symbols in the begging of the row, next to the added from the UI (see the attached screenshot). Do you mean the same behavior, or there is something more serious (attributes not added at all, etc.) My first supposition is that there is some problem in the template code. I need a time to investigate the reason. My big question is related to the alternative mapping XML support. I’m aware with the limitation, described in bug 152461. However I tried to create file manually and to manipulate it, but unfortunately without success. Could you give me a hint how I could implement this support (possible workaround), or I have to wait for the official solution. PS: I have attached a patch with few minor corrections.
Created attachment 93378 [details] screenshot with broken formating of the generated class The screenshot, mentioned in Comment #16
(In reply to comment #16) > Created an attachment (id=93377) [details] > patch with some minor corrections > > I'm very glad to hear this good news from you. About the IP related question: > Yes, I have developed 100% of the code in the patch, and I have permission to > contribute the wizard to Dali. For the integrated control “entity table – Thanks. > add/edit entity dialog” (the control from the second page) I have utilized an > idea from org.eclipse.jst.j2ee.internal.wizard.StringArrayTableWizardSection, > adapting it to my specific model. The algorithm for the implementing of That is fine, it is all EPL. > equals() and hashCode() methods in ID class is implemented in accordance with > the recommended practice from the book "Effective Java" by Joshua Bloch. This I can tell you from experience that this will probably not go well with the IP review. They will need to review any copyright from the book, the compliance with EPL, and determine the original pedigree of the code. My suggestion is to just emulate what we generate for equals() and hashCode() in Entity Generation, and remove the reference to the book. This may seem heavy handed, but it will make the process much easier. > note is added as a comment in the generated class. The lack of comments in JET > templates, due to the fact that the comment tags, described in the help link > follow, didn’t worked correctly: > http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.jet.doc/references/syntax/jetSyntaxComments.xhtml > The “commented” texts appeared in the generated templates, broken the > generation of artifacts. I will investigate deeper the issue. Even though using JET templates seems like a good idea at first, it may not be the best way to go. That said, I am fine with the usage of JET templates in this case, since you guys will hopefully be helping to maintain this code in the future. > I saw the formatting issue after the generation. On my side it appears as > missing blank symbols in the begging of the row, next to the added from the UI > (see the attached screenshot). Do you mean the same behavior, or there is > something more serious (attributes not added at all, etc.) Yes, this is the exact problem I am seeing. The screenshot confirms it. > My first supposition is that there is some problem in the template code. I need > a time to investigate the reason. The fun with JET continues. : ) > My big question is related to the alternative mapping XML support. I’m aware > with the limitation, described in bug 152461. However I tried to create file > manually and to manipulate it, but unfortunately without success. Could you > give me a hint how I could implement this support (possible workaround), or I > have to wait for the official solution. I don't think there is any plausible workaround at this time. The only workaround I can think of would be to add some functionality to Dali that would allow the user to specify specific XML Mapping files in their project as XML Mapping files. You would then have to figure out how to use our resource model to load a specific Mapping File by that user specified name. There might be other problems where supporting multiple mapping files might require other changes in our persistence unit model. We are hoping to make this happen, but currently we seem to be quite stuck given our usage of ArtifactEdit. As an adopter, perhaps you can make our bug 220395 on this topic a hot bug to add pressure. > PS: I have attached a patch with few minor corrections. >
Created attachment 93622 [details] changed hashCode() method In the context of your last comments, I have corrected the following open issues: 1. I changed hashCode() method in accordance with the style, applied from the JDT action “Source->Generate hashCode() and equals()”, and respectively remove the comments. I think that this will solve the potential problems during IP review. 2. I fixed the issue with bad format of the generated java classes. As I supposed, the problem was in the existing white spaces instead of TAB symbols in the JET templates. 3. I added in the predefined entity field types Byte[] and Character[], which I had omitted 4. Change the checkability after entity field type editing – it was missing
Thanks Dimiter. I have opened CQ 2216 to get approval for this contribution.
*** Bug 131103 has been marked as a duplicate of this bug. ***
This code contribution has been approved by Eclipse Legal, and as a result we can now request an exception for this to be committed and released in WTP M7. This is an adopter contribution (SAP). Requesting PMC approval.
Patch committed with minor modifications. This will be released for this weeks I-Build.
mass change to add 'contributed' keyword based on bugzilla query, please correct if that's not accurate (by marking patches as obsolete and removing the 'contributed' keyword.
Verified in wtp-sdk-I-I20080501032258-20080501032258.zip
Closing
