Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] best way to deal with classpath of changing jar files?

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.

On Wed, Sep 24, 2008 at 22:36,  <raccah@xxxxxxxxxxxx> 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
> wtp-dev@xxxxxxxxxxx

Back to the top