Also, why not depend on openjpa or openjpa-all like the openjpa-maven-plugin does, but allow the user to choose which level of OpenJPA the tool will use for common code reuse?
For example, there doesn't seem to be any depends or reuse of existing code in openjpa-lib or other modules. I saw usage of java.util.logging.* instead of the LogFactory in openjpa-lib. Didn't see usage of any localizer.properties or the ResourceBundleProvider. Didn't see any ANT task providers like for the MappingTool and SchemaTool. . . . Seems that reusing existing code in openjpa-lib would save us time in the long run. -Donald On 7/26/10 3:41 PM, Pinaki Poddar wrote: > > Here is a *suggested requirement* list : > > 1.1: The tools should be available in a separate openjpa-tools.jar. > Because at this stage openjpa-tools.jar should evolve faster than openjpa > releases. > > 1.2: The openjpa-tools.jar should be separate download from the usual > download page. > > 1.3: The tools documentation should be separate from openjpa documents. > > 1.4: The docs can be packaged in the openjpa-tools.zip. > > > All these requirements has "at this stage" flavor. These choices will evolve > with the progress of this exercise. > > Thoughts? > > > > > > ----- > Pinaki
