Bugzilla – Full Text Bug Listing
| Summary: | Give adopters an option to turn off/not show the Generate->JAXB classes... action | ||
|---|---|---|---|
| Product: | [WebTools] Dali JPA Tools | Reporter: | Keith Chong <keith.chong.ca> |
| Component: | JAXB | Assignee: | Neil Hauge <neil.hauge> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, neil.hauge, shaun.smith, theivend, tranle1 |
| Version: | 2.3 | ||
| Target Milestone: | 3.1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Keith Chong
This menu item performs simple JAXB class generation, yes. It can be used in conjunction with JPA, but can of course be used independently as well. JAXB generally falls under the Java Persistence Tools domain. I think the ideal way to customize this experience would be through the use of Capabilities (which we should already have, but haven't had requests for in the past). The other option would be to have JAXB support in a separate feature altogether, but this would involve the creation of a new Dali JAXB/OX feature and the creation of a JPA feature, of which there would then be an umbrella Dali feature to contain these. This may make sense for the future, but not sure this is a good short term solution. Perhaps we could quickly introduce a capability for this which would allow an adopter to turn off this particular menu item. We may want to do the same for JAXB Schema generation as well. Is this going to be a hot bug request for Helios, or something that could go into 3.2.1? David, Are there any inherent problems with delivering Dali capabilities in a patch release, post Helios? As you know, we haven't done this in the past and I would prefer not to rush changes like this into RC4/5 given our lack of experience, unless it is necessary. This is assuming that Capabilities are the correct solution for this problem. No, no problem with patch release. We don't actually "release" them at all! :) Well, not as part of our main code stream. We "document" them, and while we do include some as part of the Eclipse Java EE IDE, those are technically examples. Any "product" that wants to to make use of WTP Capabilities has to include in their own product definition/bundles. Perhaps you could just document here what that capability would look like? But yes later we could add to Java EE IDE during maintenance release. For our Helios required documentation, see http://wiki.eclipse.org/WTP_Capabilities_Helios (In reply to comment #3) > No, no problem with patch release. We don't actually "release" them at all! :) > > Well, not as part of our main code stream. We "document" them, and while we do > include some as part of the Eclipse Java EE IDE, those are technically > examples. Any "product" that wants to to make use of WTP Capabilities has to > include in their own product definition/bundles. Perhaps you could just > document here what that capability would look like? But yes later we could add > to Java EE IDE during maintenance release. For our Helios required > documentation, see > > http://wiki.eclipse.org/WTP_Capabilities_Helios That makes sense. Basically we just need to document how to do it (what the regular expression would look like, etc), and then the adopter actually owns the content that they decide to include. I knew someday I would need to learn about Capabilities. : ) Kim's article is quite helpful. Targeting to Juno release. JAXB functionality has been separated out into its own feature and plugins as of Indigo, so this functionality can be easily removed by not including org.eclipse.jpt.jaxb bundles and features. Capabilities could also be used for more granular tuning. |