The wildcard mechanism is already in place for generic server classpaths. The JBoss generic server adapter uses it, take a look at the jboss.serverdef for an example. We do not have anything for 2. It is hard for generic server framework to detect if a functionality exists and remain generic. -- Gorkem
On Wed, Sep 24, 2008 at 22:36, <[EMAIL PROTECTED]> wrote: > We're using the generic server adapter framework and the > GenericServerRuntimeTargetHandler for the runtimeClasspathProviders > extension. We have a list of jar files in a <classpath></classpath> entry > in our serverdef. The problem is, the list of jar files in our server keeps > changing, and it's quite difficult to keep up with it, and even if we keep > up with it, if a user gets a different plugin version than the one meant to > work with a particular server build, he's kind of stuck. > > These are the types of jar file changes that occur: > 1) some string in the jar file name (like version number) is either > added/modified/removed > > 2) some jar files are optional - they may be found in a server with a > particular functionality enabled, but not in another server which is > barebones. If the functionality exists, I would like it automatically in > the build path. > > 3) renaming/changing of the jar file contents > > I think for 1, a regex/wildcard type functionality would help. For 2, I > could see marking something as optional. For 3, I don't know of any way to > work that in.... > > My questions - > Is it possible to account for these types of changes in an > xml/serverder/classpath definition? > > If not, is my option to provide an alternate (java based) classpath > provider? If yes, is there a good example for me to look at somewhere? > > Thanks, > Rochelle > _______________________________________________ > wtp-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/wtp-dev > _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
