Latest revision as of 13:02, 14 October 2010

Remove module facet dependence

Remove dependence on module-installed natures

• JavaEMFNature - Doesn't appear as though the absence of this nature affects Dali. It's hard to tell exactly what this nature is doing, however.
• ModuleCoreNature - This is primarily for setting Java EE module dependencies and defining build structure. We don't need the first (if we do, we'll coexist with a module, and that will provide the nature) and we currently *do* use the second to resolve deployment paths to source files. This mechanism currently doesn't work (well) with "SE" java projects, OSGi projects, or Maven projects. We should provide a pluggable mechanism to do this for us, depending on what situation above (including unlisted situations) exists. see here
  • (update 7/30/10) I've also determined that this nature is used for enabling the resource factories extension point for using the translator framework. I believe I have a way to work around that.

Project creation/modification

• Provide alternate path to creating non-JEE project. Current wizard extends utility module wizard. We'll still want the ability to specify project name, location, runtime, configuration (facets), and (optionally) working sets, but EAR membership obviously won't apply. We may want to have a JPA SE wizard and a JPA EE wizard which maintains the existing JPA/utility project creation path.
• JPA facet configuration - Currently we use wtp extensions of "User library" and OSGi library providers. In the case that the project is not a Java EE project, we'll want to use non-wtp extensions. The difference between wtp and non-wtp extensions is the ability to "Include libraries with this application". There will likely need to be two different configuration pages depending on whether the project is currently configured to be SE or EE (based on module facet presence). Migration between EE and SE may be problematic as these library providers will look almost identical in the list.

Resource locator (?) extension point

• We should be able to calculate an ordered list of locators for a given project. We would then use the first locator to determine the default location for resource files. We'd use them in order to try and resolve a real file from a deployment path.
• Requirements
  • A locator class: something which can both tell us where to put resources and how to resolve deployment locations to actual files.
  • Some sort of enablement or tester. We should probably stick with existing enablement mechanism here. see [[1]]
  • A priority of some type. There is no set standard, but something like low|normal|high should be enough.
    • (7/30/10) I've elected to go with lowest|lower|low|normal|high|higher|highest since I'm already using four of them.

ResourceLocator interface

public interface ResourceLocator {
 
    /**
     * Return whether the given container is an acceptable (non-java) resource 
     * location for the given project
     */
    boolean acceptResourceLocation(IProject project, IContainer container);
 
    /**
     * Return the default location in which to create new (non-java) resources
     */
    IContainer getDefaultResourceLocation(IProject project);
 
    /**
     * Return the workspace relative resource path best represented by the given 
     * runtime path for the given project
     */
    IPath getResourcePath(IProject project, IPath runtimePath);
 
    /**
     * Return the runtime path best represented by the given workspace relative absolute
     * resource path for the given project
     */
    IPath getRuntimePath(IProject project, IPath resourcePath);
}

Questions

• Do we want to have a resource locator return an array (or some other construct) of IFolder objects, or should it test a given resource location instead? (e.g. boolean acceptResourceLocation(IProject project, IFolder folder);)
  • (7/30/10) I have elected to go with the latter approach
• I think the second method is correct. We can only generate files into folders.
  • (7/30/10) Changed the second method to use IContainer so that we *could* generate into a project
• I think we want to use IPath for the third method, because eventually we want to support archive entries and potentially cross project references. Workspace relative IPaths leave room for this at some point.
  • (7/30/10) Although I do not think we want to use this for archive references, we still may want to refer to xml files in strange locations
• (8/4/10) Added getRuntimePath(IProject, IPath) for purposes of adding references to persistence.xml

sample extension

<extension point="org.eclipse.jpt.core.resourceLocators">
    <resourceLocator 
        id="javaResourceLocator"
        class="org.eclipse.jpt.core.internal.JavaResourceLocator"
        priority="low">
        <enablement>
            <with variable="project">
                <test property="org.eclipse.wst.common.project.facet.core.projectFacet" value="jst.java" forcePluginActivation="true"/>
            </with>
        </enablement>
    </resourceLocator>
</extension>