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?

Thanks, Gorkem, that is quite helpful. I had tried the wildcard before, but in an archive definition, not an include one. So, looking at the jboss file, I see the use of the wildcard in include/fileset portions of the classpath and that works nicely. The only problem is, it seems that at least one archive line is still required
jboss has this:
<!-- leave one generic jar as an archive so that validation works -->
<archive path="${serverRootDirectory}/server/default/lib/mail.jar" />

So, what do I do if all my jars fall into this category (1) of might have a version number or might not? How can I define my classpath in that case? If I put them all in include/fileset, then I get an error in the wizard that there is no classpath defined. If I try to include one archive, then I am hardcoding it to a particular version....

Thanks,
Rochelle


Gorkem Ercan wrote:
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,  <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
https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


Back to the top