Bugzilla – Full Text Bug Listing
| Summary: | [EclipseLink] Support invocation of JAXB schema compiler to generate Entities | ||
|---|---|---|---|
| Product: | [WebTools] Dali JPA Tools | Reporter: | Shaun Smith <shaun.smith> |
| Component: | JAXB | Assignee: | Tran Le <tranle1> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | neil.hauge, paul.fullbright, tranle1 |
| Version: | 2.3 | Keywords: | plan |
| Target Milestone: | 2.3 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Shaun Smith
Ideally this feature would consist of a generic implementation using the base xjc, and allow for provider specific implementations or customizations. Assumptions: We will only support JAXB 2.2, which EclipseLink is slated to support in EL 2.1. This functionality could be contained in the following new plugins: org.eclipse.jpt.jaxb.core - facet core - JAXB platform extension point org.eclipse.jpt.jaxb.gen - JAXB gen main org.eclipse.jpt.jaxb.ui - JAXB wizard UI org.eclipse.jpt.jaxb.eclipselink.core - facet core - JAXB platform extension org.eclipse.jpt.jaxb.eclipselink.gen - EclipseLink specific JAXB gen main org.eclipse.jpt.jaxb.eclipselink.ui - EclipseLink specific JAXB gen UI 2 new features would be required to house the functions: org.eclipse.jpt.jaxb.feature org.eclipse.jpt.jaxb.eclipselink.feature Alternatively, a more lightweight strategy could potentially be used to fulfill this request. More thinking would need to be done to determine how this might work in the context of WTP. Another possibility would be a code donation in this area which we could then build on. Thinking a bit more on the lightweight approach... We could have one new plugin that simply provides a menu item to perform generic JAXB class gen from an .xsd on any Java project (negating the need to involve a JAXB facet, and the overhead that would come from that). This plugin could also provide an extension mechanism to allow for provider specific JAXB gen. A second plugin would contain the EclipseLink based JAXB generation. This plugin would implement the extension to augment the generic generation to use its own JAXB gen. In this approach there are no new Facets and no "Platforms". So perhaps: o.e.jpt.jaxb.gen - Generic JAXB forward and reverse generation - JAXB vendor extension point o.e.jpt.jaxb.eclipselink.gen - EL specific JAXB forward and reverse generation - implement vendor extension Here is a proposal for the UI. Feedback is welcome. Class generation should be available via a right-click on an XSD file in any Java Nature or Java faceted project. The menu item for this action will be located in the existing "Generate" menu for XSD's, and will have a menu item label of "JAXB Classes from Schema...". "Generate -> JAXB Classes from Schema..." This will open up a wizard (1 page should be sufficient) that will guide the user through the generation process. This wizard should contain at minimum options for: - Source folder (option/link to create new source directory would be nice here) - Java package Additional input could include: - XML catalog file - JAXB binding files (would require an add/remove list) This covers the generic only case. In the case where the Dali o.e.jaxb.eclipselink.gen plugin exists, an additional checkbox would need to be added (via an extension) to allow the user to specify EclipseLink as the JAXB implementation. Such as: [ ] Use EclipseLink MOXy as the JAXB implementation This would have the added effect of creating a file called "jaxb.properties" with the following property added: javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory Since EclipseLink JAXB class generation is only a facade to the generic implementation, a simple way to implement the class generation wizard is to have the check box appears only when the JTP EclipseLink JAXB plugin is present at runtime. This will avoid the complexity of creating an extension. The drawback of this implementation is that it doesn’t allow adopter to extend Dali support for JAXB. Notes from weekly meeting: - Library config support as first step in the wizard would be nice. Need to determine if we can do this without adding a JAXB facet. Would also need a project properties page for JAXB to manage library config. - Intead of having an EclipseLink implementation checkbox, it may make more sense to just assume that if the EclipseLink MOXy libraries are present in the project classpath we should use the EclipseLink compiler. - For extensibility we should add the ability to pass args (programmatically or user entered) to the generation process. This will allow xjc compiler plugins to execute when run. We need to make sure we get the WTP build configured to support this feature before M6 begins to shutdown. Proposal for library configuration assistance:
This seemed somewhat straightforward at first, but there are a couple of different ways we could go here with the library help. First I will say that we won't attempt to use the Library Configuration framework for this, given the time constraints and the issues of managing this additional metadata. We will perform similar validation of what is on your classpath, and offer guidance on library configuration, which we will link to for convenience.
"Generic" and "EclipseLink" represent Dali plugin availability in the chart below. The term "prompt" is used in the chart to identify where a library configuration help page will be added. This page will need to be at the end of the wizard so that we have a chance to ask the user if they wish to use EclipseLink MOXy, in the specific case where the Dali EclipseLink jaxb bundle is available but the underlying EclipseLink MOXy library is not. Or, we simply have the library prompt first, and always warn that the MOXy libraries aren't available in the case where they are not, and the Dali MOXy plugin is.
| JDK 1.5 | JDK 1.6
Generic Need to prompt No need to prompt
if JAXB package
not available
------------------------------------------------------------------
EclipseLink Need to prompt Need to prompt if
if EclipseLink EclipseLink package
package or JAXB is not availablle
package is not
available
For generic cases:
"The classpath for this project does not appear to contain the necessary libraries to proceed with class generation. Please insure that a JAXB implementation is available on the classpath."
For MOXy cases:
"The classpath for this project does not appear to contain the necessary libraries to proceed with class generation. Please insure that EclipseLink MOXy is available on the classpath."
An additional requirement that was raised for generation would be to allow generation from a schema on the file system (not in the Project) or any resolvable URL. This will likely have to be follow on work to this enhancement. This is complete for M6. Please open new bugs for problems or enhancements with this feature. Verified by generating JAXB classes from a schema in RC2 |