a problem of classpath too long
by feng.qian
Hi all,
There is a problem about classpath.
Up to now, the jboss ws module of our tools use two commands --
'wsprovider.bat' 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
17 years
Re: Tests on hudson
by Max Rydahl Andersen
Hi Daniel,
From what I can see on that list it seems the seam version we are
"asserting" against is not installed.
Nick/Denis, how are these actually configured on hudson if at all ?
/max
> ----- Original Message -----
> *From:* Daniel Azarov <mailto:daniel@exadel.com>
> *To:* Jboss Devstudio Dist List
> <mailto:jboss-devstudio-list@redhat.com> ;
> external-exadel-list(a)redhat.com <mailto:external-exadel-list@redhat.com>
> *Sent:* Friday, February 27, 2009 10:45 AM
> *Subject:* Tests on hudson
>
> I compared test results on my computer and on hudson (last build #781
> (26.02.2009 18:10:23) )
> There is big difference. For example, all
> org.jboss.tools.seam.core.test.project.facet.* tests on my computer
> passed ok
> But hudson said next:
> junit.framework.AssertionFailedError: /srv/hudson/jobs/redhat-jbosss-tools-nightly/workspace/jbds-build/3.0.0.CR1/200902261812/tests/jboss/jboss-eap-4.3/seam does not exist
> at org.jboss.tools.seam.core.test.project.facet.AbstractSeamFacetTest.assertSeamHomeAvailable(AbstractSeamFacetTest.java:263)
> at org.jboss.tools.seam.core.test.project.facet.AbstractSeamFacetTest.setUp(AbstractSeamFacetTest.java:83)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> ...
> It seems there are problems on hudson with build
17 years, 1 month
SOA-P 4.3 vs EAP 4.3
by Denny Xu
When I try to create a WTP adaptor for SOA-P 4.3 using JBoss 4.2 Runtime
type, get a warning message:
"The home directory does not exist, is missing key files, or is of the
incorrect version",
so I changed the runtime type to JBoss Enterprise Application Platform
4.3 and set runtime home directory to
a JBoss SOA-P 4.3, it works, then I apply the runtime library to a project,
it shows **JBoss Enterprise Application Platform 4.3 Runtime[...]* *in
the project's Libraries list.
Are SOA-P and EAP the same thing? if I understand correctly, EAP is not
the same as SOA-P,
since the EAP does not contain ESB runtime but SOA-P does, right? if
so, users might be confused when
using EAP and SOA-P in JBoss Tools.
I ask this because I am in the situation when try to create some out of
the box ESB project examples,
I want to set the SOA-P classpath container to the projects classpath,
so they can work with ESB
runtime support, users just need create a JBoss SOA-P runtime with the
same name specified in
project examples in their workspace after they import the project
examples, but for now, there
is not a separate server runtime type for JBoss SOA-P, if using EAP
runtime, users might create
a EAP runtime and can't make it works, users would be depressed.
Denny
17 years, 1 month
A Modest Proposal
by Rob Stryker
I'd like to propose that after the 3.0 release, we branch to a
3.0_maintenance and use that for 3.0.1. This will leave TRUNK open for
further development and new features. I realize this is not how we've
done it in the past. In the past we'd branch to 3.0.0 a few days before
release, and then future work would go into TRUNK for 3.0.1. But I
think this is the proper way to do things.
I don't have many "bug fixes" for the 3.0.1 release. In fact, after
scanning my list, almost all are new features, not bugs. I clearly see
me implementing new features as something that should go in TRUNK and
not something I should have to branch my own project for.
Any thoughts?
17 years, 1 month
