[JBoss-dev] jboss-3.2-testsuite build.220 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060213052218Lbuild.220 BUILD COMPLETE-build.220Date of build:02/13/2006 05:22:18Time to build:51 minutes 36 secondsLast changed:02/11/2006 05:27:52Last log entry:Make this compile on JDK1.3 Unit Tests: (1848) Total Errors and Failures: (0)All Tests Passed Modifications since last build:(first 50 of 1)1.4.4.3modifiedadriantestsuite/src/main/org/jboss/test/jca/xads/Test.javaMake this compile on JDK1.3
[JBoss-dev] jboss-cache-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060213065459 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-JBossCache.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/13/2006 06:54:59Time to build:40 minutes 2 secondsLast changed:12/28/2005 10:48:11Last log entry:Add the 1.2.4SP1 changelog notes. Unit Tests: (1351) Total Errors and Failures: (51)testorg.jboss.cache.ConcurrentEvictAndRemoveTesttestSimplifiedorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestSimplifiedorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestDataSourceIntegrationorg.jboss.cache.loader.DataSourceIntegrationTesttestCheckReplInstanceorg.jboss.cache.aop.ReplicatedObjectGraphAopTesttestCollectionWithCacheLoaderorg.jboss.cache.aop.loader.FileCacheLoaderAopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer1241AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer124AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer130AopTestwarningorg.jboss.cache.benchmark.support.BaseTestwarningorg.jboss.cache.benchmark.support.Read50PercentTestwarningorg.jboss.cache.benchmark.support.Read75PercentTestwarningorg.jboss.cache.benchmark.support.Read90PercentTestwarningorg.jboss.cache.benchmark.tests.HashMapRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead90JRunitTesttestUpdateEvictionorg.jboss.cache.eviction.AopLRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.FIFOPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LFUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.MRUPolicyTesttest2ReadersAnd1Writerorg.jboss.cache.lock.ReentrantWriterPreferenceReadWriteLockTestwarningorg.jboss.cache.optimistic.LocalCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticTestwarningorg.jboss.cache.optimistic.LocalTesttestGetChildren9Passivationorg.jboss.cache.passivation.PassivationToBdbjeCacheLoaderTesttestGetChildren10Passivationorg.jboss.cache.passivation.PassivationToBdbjeCacheLoaderTesttestGetChildren9Passivationorg.jboss.cache.passivation.PassivationToFileCacheLoaderTesttestGetChildren10Passivationorg.jboss.cache.passivation.PassivationToFileCacheLoaderTesttestGetChildren9Passivationorg.jboss.cache.passivation.PassivationToLocalDelegatingCacheLoaderTesttestGetChildren10Passivationorg.jboss.cache.passivation.PassivationToLocalDelegatingCacheLoaderTesttestNonSerizlableReplorg.jboss.cache.replicated.ReplicationExceptionTesttestNonSerizlableReplWithTxorg.jboss.cache.replicated.ReplicationExceptionTesttestConcurrentUseAsyncorg.jboss.cache.statetransfer.StateTransfer130TesttestConcurrentAccessWithRWLockorg.jboss.cache.transaction.ConcurrentTransactionalTesttestNodeCreationRollbackorg.jboss.cache.transaction.IsolationLevelReadCommittedTest Modifications since last build:(first 50 of 1599)1.3modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaFixes rating to JBCACHE-118 - optimising cache loader functionality.1.2modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.1addedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.2modifieddhuangtests/stress/org/jboss/cache/EvictionLocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce
RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
In our current configuration, the jar plugin is not adequate. For a
given module, we need to build many artifacts (see the build forum post
here):
http://www.jboss.com/index.html?module=bbop=viewtopicp=392#392
I spent some time looking at the assembly plugin as well, but did not
find it suitable for the following reasons.
1) It must be called manually. We don't want to have to call this for
each module.
2) It lacks functionality for adding classes from dependencies into a
jar. E.g, I want to create a jar and add some classes from another
modules output.
3) It seemed to me overall that the assembly plugin was best used for
creating the final project structure, not for building the outputs of
each subproject.
If I am wrong, please correct me.
Ruel Loehr
JBoss QA
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim
OBrien
Sent: Sunday, February 12, 2006 12:36 PM
To: jboss-development@lists.sourceforge.net
Subject: Re: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing
build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
Seconding Adrian's suggestion below. Here's a pointer to Apache Axis2's
Subversion repository as
a cautionary example that is related to using Ant tags in Maven builds:
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/maven.xml
They moved to Maven 1, but they did so by just adapting existing Ant
build scripts into a
maven.xml file. Check out the trunk of Axis2; try to understand the
build system, and I think
you'll quickly come to the conclusion that Axis2 doesn't use Maven. It
uses Maven as a wrapper
around a core build that is still written in Ant. When a project moves
to Maven by wrapping
existing Ant build scripts, the end product is neither an Ant build nor
a Maven build, it is a
custom Frankenstein build that gains no benefit from Maven's life-cycle;
it doesn't benefit from
the reuse that are Maven plug-ins, and it takes just as much work to
manage as the original.
In the last two years most people have moved to Maven 1 from Ant, and I
don't think that the Maven
people did a good job of letting people know not to do this [make heavy
use of Ant tags]. People
tended to put customizations in maven.xml and then they had a bad
experience with Maven 1. (Then
they read the BileBlog, and now there is a siginificant portion of the
population that *hates*
Maven.)
Maven 2 was redesigned from the ground up to discourage build
customization via Ant tags. In
general, Maven 2 can handle almost anything you can throw at it, and,
when it can't, it is easy to
write a script in the form of a plugin (and if you really want to write
that plugin in Ant see:
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html)
What you are trying to do below is already handled by the jar plugin and
if that doesn't meet your
needs you can create an assembly descriptor. But, I wouldn't expect
people to just know that
because the docs are lacking.
I wouldn't recommend using the antrun plug-in even as a temporary
stop-gap. If you are going to
move to Maven 2, adopt it in full; otherwise, you'll end up in the same
situation as Axis2.
You'll have semi-adoption of Maven 2, but most of your build logic will
still be captured in Ant.
--- Adrian Brock [EMAIL PROTECTED] wrote:
On the maven build in general, I don't like the kind of thing
seen below. We might as well use ant than learn a new tool
to do this???
Good: Declarative information known to the build system
Bad: Scripting or any other hack that breaks the information trail
Is this just because our projects are hopelessly entangled?
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.0/version
executions
execution
!-- instruct maven that this plugin should be
executed whenever the package phase is ran
--
phasepackage/phase
configuration
tasks
mkdir dir=${basedir}/output/lib/
!-- Build jboss-common.jar --
jar
jarfile=${basedir}/output/lib/jboss-common.jar
manifest=${basedir}/src/etc/default.mf
fileset
dir=${basedir}/output/classes
include name=org/jboss/**/
include
name=org/apache/xerces/**/
/fileset
/jar
!-- Build jboss-common-client.jar --
jar
jarfile=${basedir}/output/lib/jboss-common-client.jar
RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
We are mixing several issues here though. 1. Ruel's attempt to replicate the build using maven was a question as to whether maven could handle a screwed up build structure. 2. Since this is not ideal and maven has an even stricter notion of a source tree/per artificat, should the build be restructured to more closely mirror this notion to remove the hacks Ruel used. 3. There are additional changes being discussed with regard to breaking up existing cvs modules and artifacts (common - jboss-common.jar) to separate out projects like jbossxb which should be evolvoing indepedently of the app server. 4. svn blah blah. The point I take from Adrian is that if we have to do something beyond what maven supports via an existing plugin, it needs to be encapsulated in a custom plugin. It cannot be ad hoc scripting in the build descriptors. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruel Loehr Sent: Monday, February 13, 2006 8:44 AM To: jboss-development@lists.sourceforge.net Subject: RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff In our current configuration, the jar plugin is not adequate. For a given module, we need to build many artifacts (see the build forum post here): http://www.jboss.com/index.html?module=bbop=viewtopicp=39233 33#392 I spent some time looking at the assembly plugin as well, but did not find it suitable for the following reasons. 1) It must be called manually. We don't want to have to call this for each module. 2) It lacks functionality for adding classes from dependencies into a jar. E.g, I want to create a jar and add some classes from another modules output. 3) It seemed to me overall that the assembly plugin was best used for creating the final project structure, not for building the outputs of each subproject. If I am wrong, please correct me. Ruel Loehr JBoss QA --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: concurrent-testsuite Build Completed With Testsuite Errors
This test is failing because it makes an invalid assumption. That is that a privileged block will run with exactly the instance of the access control context you pass it. This is not true because it can do things with the domain combiner to create a new equivalent access control context. Strangely, it only appears to fail when running it from junit inside ant. If I run the test indivudually from eclipse, it doesn't go through domain combination? Should I just disable the test. A better test would be to check whether the scheduled operation can perform some expected privileged action (like retrieve a system property). On Sun, 2006-02-12 at 19:15, [EMAIL PROTECTED] wrote: View results here - http://cruisecontrol.jboss.com/cc/buildresults/concurrent-testsuite?log=log20060212190745 TESTS FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-concurrent-testsuite.xml:73: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures. Date of build: 02/12/2006 19:07:45 Time to build: 7 minutes 27 seconds Unit Tests: (1707) Total Errors and Failures: (1) testPrivilegedThreadFactory .ExecutorsTest Modifications since last build: (first 50 of 0) -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: Could not run jacorb on 64 bit jdk
From: Rajesh Rajasekaran Sent: Friday, February 10, 2006 12:05 PM To: '[EMAIL PROTECTED]' Subject: Could not run jacorb on 64 bit jdk This is related to the bug #468 http://www.jacorb.org/cgi-bin/bugzilla/long_list.cgi?buglist=468 We are trying to support Jboss on 64 bit jdks and this bug is a major blocker. A fix for this ASAP would help us proceed with our process. Thanks Rajesh JBoss QA
RE: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk
Francisco, Just to make it clear, we are trying to build JBoss on 64bit JVMs and we get this fatal exception when trying to run the jacorb parser: Exception in thread main java.lang.VerifyError: (class: org/jacorb/idl/parser,method: clinit signature: ()V) Call to wrong initialization method Can you patch this? We arent getting a response from the jacorb list. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh Rajasekaran Sent: Monday, February 13, 2006 5:04 PM To: jboss-development@lists.sourceforge.net Cc: Francisco Reverbel Subject: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk From: Rajesh Rajasekaran Sent: Friday, February 10, 2006 12:05 PM To: '[EMAIL PROTECTED]' Subject: Could not run jacorb on 64 bit jdk This is related to the bug #468 http://www.jacorb.org/cgi-bin/bugzilla/long_list.cgi?buglist=468 We are trying to support Jboss on 64 bit jdks and this bug is a major blocker. A fix for this ASAP would help us proceed with our process. Thanks Rajesh JBoss QA
RE: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk
Actually, it looks like our post to the Jacorb list was a pretty bad post. We will correct this. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Campbell Sent: Monday, February 13, 2006 5:12 PM To: jboss-development@lists.sourceforge.net Cc: Francisco Reverbel Subject: RE: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk Francisco, Just to make it clear, we are trying to build JBoss on 64bit JVMs and we get this fatal exception when trying to run the jacorb parser: Exception in thread main java.lang.VerifyError: (class: org/jacorb/idl/parser,method: clinit signature: ()V) Call to wrong initialization method Can you patch this? We arent getting a response from the jacorb list. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh Rajasekaran Sent: Monday, February 13, 2006 5:04 PM To: jboss-development@lists.sourceforge.net Cc: Francisco Reverbel Subject: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk From: Rajesh Rajasekaran Sent: Friday, February 10, 2006 12:05 PM To: '[EMAIL PROTECTED]' Subject: Could not run jacorb on 64 bit jdk This is related to the bug #468 http://www.jacorb.org/cgi-bin/bugzilla/long_list.cgi?buglist=468 We are trying to support Jboss on 64 bit jdks and this bug is a major blocker. A fix for this ASAP would help us proceed with our process. Thanks Rajesh JBoss QA
RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
I read that thread and it looks like the idea is to refactor common into multiple top-level projects (option #2). If that's the case, you should be able to rely on the jar plugin as long as you are not trying to create JARs that contains classes from dependencies. --- Ruel Loehr [EMAIL PROTECTED] wrote: In our current configuration, the jar plugin is not adequate. For a given module, we need to build many artifacts (see the build forum post here): http://www.jboss.com/index.html?module=bbop=viewtopicp=392#392 I spent some time looking at the assembly plugin as well, but did not find it suitable for the following reasons. 1) It must be called manually. We don't want to have to call this for each module. In Maven2, when you execute mvn assembly:assembly from a top-level project, it will run that goal on every subproject referenced. But, this assumes that you'd want to run assembly:assembly on every subproject. 2) It lacks functionality for adding classes from dependencies into a jar. E.g, I want to create a jar and add some classes from another modules output. This is possible, but I'm not surprised that you didn't see how this is accomplished. The Assembly plugin is one of worst documented plugins of the bunch. You could create an assembly descriptor that would unpack a selected set of dependency jars. Although, I'd recommend against this. See the end of this message. 3) It seemed to me overall that the assembly plugin was best used for creating the final project structure, not for building the outputs of each subproject. I think that the most obvious use of the assembly plug-in is to use it to build final project distributions. A less obvious use would be to use it to create these JARs that contain mixtures of dependency jars. I'm just offering it as an example of something that could be done. I think the assembly plugin could probably do this, but it would be a stretch. I think this is a job for a custom plugin. Tim --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-remoting-testsuite-1.4 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.4?log=log20060213215739 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/13/2006 21:57:39Time to build:16 minutes 53 secondsLast changed:02/13/2006 15:11:38Last log entry:JBREM-310 - added flag for turning off socket connection check. Unit Tests: (146) Total Errors and Failures: (5)unknownorg.jboss.test.remoting.stream.StreamingTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization) Modifications since last build:(first 50 of 10)1.19modifiedtelrodsrc/main/org/jboss/remoting/transport/socket/ServerThread.javaJBREM-310 - added flag for turning off socket connection check.1.29modifiedtelrodsrc/main/org/jboss/remoting/transport/socket/SocketClientInvoker.javaJBREM-310 - added flag for turning off socket connection check.1.16modifiedtelrodsrc/main/org/jboss/remoting/transport/socket/SocketServerInvoker.javaJBREM-310 - added flag for turning off socket connection check.1.3modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/ClientAbortException.javaJBREM-316 - changed header apache license where appropriate.1.4modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/CoyoteInputStream.javaJBREM-316 - changed header apache license where appropriate.1.10modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/CoyoteInvoker.javaJBREM-316 - changed header apache license where appropriate.1.5modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/CoyoteOutputStream.javaJBREM-316 - changed header apache license where appropriate.1.3modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/InputBuffer.javaJBREM-316 - changed header apache license where appropriate.1.4modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/OutputBuffer.javaJBREM-316 - changed header apache license where appropriate.1.3modifiedtelrodsrc/main/org/jboss/remoting/transport/coyote/ssl/RemotingSSLSupport.javaJBREM-316 - changed header apache license where appropriate.
[JBoss-dev] jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060213221614 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/13/2006 22:16:14Time to build:72 minutes 45 secondsLast changed:12/31/2005 20:37:24Last log entry:JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup. Unit Tests: (295) Total Errors and Failures: (12)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(java_serialization)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(jboss_serialization)unknownorg.jboss.test.remoting.stream.StreamingTestCase(java_serialization)unknownorg.jboss.test.remoting.stream.StreamingTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(jboss_serialization) Modifications since last build:(first 50 of 2041)1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutTestCase.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/ComplexObject.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvocationHandler.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServer.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServerImpl.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TransporterTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/SSLInvokerConstants.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.8modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleClient.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleServer.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.7modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-270:Replaced "," with ""1.6modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-270:Replaced "," with
[JBoss-dev] concurrent-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/concurrent-testsuite?log=log20060214023209 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-concurrent-testsuite.xml:73: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/14/2006 02:32:09Time to build:7 minutes 21 seconds Unit Tests: (1707) Total Errors and Failures: (1)testPrivilegedThreadFactory.ExecutorsTest Modifications since last build:(first 50 of 0)
