If you use External Tools launch configurations you don't even need a
custom launch configuration type I would think.
...and if you used External Tools launch configurations for this users
would be able to adjust this launch if really needed.
Just a thought.
/max
> 2 call org.jboss.wsf.spi.tools.cmd.WSProvide directly.
> Thi methos has two way to realize:
> One is using classloader and the other is using eclipse launch
> configuration(as Rob said)
> These two ways both need to load some jars according to the
> wsprovider.sh. I do not know if these sh are same from different
> verion of jboss AS or WS. So I tested them and know they can
> resolved the issue. But I do not use it.
eh - why not ? this sounds by far as the best solution and you can
always have variations of it dependent on wether it is AS or WS you
are using.
And you would need to know that for what you do in solution 4 anway,
right ?
> 4 create a temp.jar and add all of the jars into the temp.jar's
> menifest file. Then use this jar instead of all of the jars to the
> class path
> Now I use this method to resolve this issue.
This does not sound like a good idea! Classloading rules changes when
stuff is put into the same jar plus it is not how the user would run
these
if he could. Plus it requires a massive copying of classes/files.
> 5 maybe have another way from a runtime guy: change the .sh file
> and add all of the jars into the command line classpath, then run
> the command as: wsprovider.sh -w -k ............. thejavaclass
> The wsprovider.sh call org.jboss.wsf.spi.tools.cmd.WSProvide. I
> have study the codes of the class, it create a classloader to run and
> the classloader will extend parent's classpath. So we can use the
> method to resolve this issue.
> But we need to get the wsprovider.sh and modify it, then run.
> I do not test it.
>
> At the end, I think jboss ws team should offer a class to handle this
> issue because in command line, the issue occurs too.
Or we need to investigate which jars we *actually* need to pass on to
WS for it to work ?
/max
>
> Grid
>> Hi all,
>>
>> There is a problem about classpath.
>> Up to now, the jboss ws module of our tools use two commands --
>> 'wsprovider.sh' and 'wsconsumer.bat' -- to generate codes
>> in both scenes: bottow-up(from a java class) and top-down(from a
>> wsdl file).
>> When we call wsprovider.bat to generate codes, we may create a
>> command to run in our eclipse console like this:
>> wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
>> ............. thejavaclass
>> My codes run this command like this in my plugins:
>> Runtime rt = Runtime.getRuntime();
>> rt.exec(command.toString(), null, new
>> File(commandLocation));
>> On linux, this is ok. But on windows, a error occurs: the command is
>> too long. This is caused by the classpath parameter is
>> too long because we add very many jars to '-c'
>> I think, in enterprise scenes, we will often meet this problem --
>> need to add many jars to classpath.
>> So I want to ask if we have a way to set a container or a jars
>> folder for these jars.
>>
>> Thanks
>> Grid
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev