Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Dali/Indigo/RemovingModuleFacetDependence

< Dali‎ | Indigo
Revision as of 15:21, 18 June 2010 by Paul.fullbright.oracle.com (Talk | contribs) (fixed link)

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

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 "User library" and OSGi library providers that extends the wtp version of those library provider types. In the case that the project is not a Java EE project, we'll want to replace those with 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.

ResourceLocator interface

public interface ResourceLocator {
 
    IFolder getDefaultResourceLocation();
 
    IFile resolveDeploymentPath(IPath deploymentPath);
}

sample extension

<extension point="org.eclipse.jpt.core.resourceLocators">
    <resourceLocator 
        id="javaResourceLocator"
        class="org.eclipse.jpt.core.internal.JavaResourceLocator"
        priority="low"/>
</extension>

Back to the top