Uploaded image for project: 'JBoss Modules'
  1. JBoss Modules
  2. MODULES-153

Ability to discover all jars available to a generic application for a non-running server with a given config file

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Won't Do
    • Icon: Critical Critical
    • None
    • None
    • Core
    • None

      Not sure if this is 100% the domain of modules, or if it bleeds into AS. Either way:

      Tooling is looking for a stable way to get a list of jars accessible for a generic project (web, sar, custom) which will be deployed to the AS, for the purposes of modifying an eclipse project's classpath to provide these jars in the workspace.

      The current method under investigation is a PoC found here: https://github.com/rafabene/jboss-modules-poc, though we intend to bend it to our own purposes of course

      We have been advised that simply poking around the modules folder is not a sustainable or guaranteed way to acquire this list of jars, and so we're looking for something a bit more stable.

      The idea here would be to generate a classpath that would assist the developer in developing his application. We are looking to avoid jars with duplicate class entries (jsf1, jsf2, etc etc).

      It would be best if we could somehow limit this to only what jars the application will be able to access, but I am not sure if this is feasible considering the application is of indeterminate type (sar or web, etc, we do not expect jboss-modules to be able to figure that out or even respond should we provide it. My feeling is that would not be feasible for jboss-modules)

      So again, we'd like some solution that is not necessarily a minimal set of jars required, but at the very least contains no duplicates that would hinder the developer's coding progress. (Duplicate entries in eclipse could cause errors on deployment if, for example, it was compiled against jsf1 but was deployed to jsf2)

      In general we do not intend to bundle jboss-modules.jar at all since it is likely to change substantially from version to version as new features are added, so tools will most likely access this via reflection (loading the jar via a classloader in an isolated thread and then disposing of ti later after our query has finished).

      For this reason we would like at least this jira's suggested api to be stable and backwards compatible.

      So, basically, given a jboss installtion (or modules folder), and a configuration file (standalone.xml or similar), we would like a list of jars we could add to a projects classpath.

      Is this do-able?

              Unassigned Unassigned
              rob.stryker Rob Stryker (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: