Re: [wtp-dev] best way to deal with classpath of changing jar files?

["Gorkem Ercan" <gercan@xxxxxxx>]

When we added the wildcard feature for supporting JBoss, it was not
necessary to touch the UI validation. Perhaps we should make the
validation of the UI more intelligent so that we get the full
benefits.  Would you mind opening an enhancement request for this so
that we can continue with the discussion over there.
--
Gorkem


On Fri, Sep 26, 2008 at 02:27,  <raccah@xxxxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>