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
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.
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 ?
> ----- Original Message -----
> *From:* Daniel Azarov <mailto:firstname.lastname@example.org>
> *To:* Jboss Devstudio Dist List
> <mailto:email@example.com> ;
> external-exadel-list(a)redhat.com <mailto:firstname.lastname@example.org>
> *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
Say hi to Ronald van Kujik aka kukeltje our newest external committer to
You can see why and on what basis Ronald got his access at my latest
We don't know yet what it will grow into, but I welcome the eagerness!
Welcome Ronald :)
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
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.
I have adapted the simple project from the RESTEasy distribution to a
JBoss Tools Project example.
You may want to take a look at http://screencast.com/t/PmXyXl5Nd
I am going to add some more RESTEasy examples.
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.