Ongoing build changes: was RE: [JBoss-dev] On the edge of the Maven cliff
On a related issue. I really want to bite the bullet on sorting out the jboss-common dependencies and making more managable chuncks for standalone projects to eat. I've been waiting for the ongoing build changes to stabalise before doing this in jboss-head. This would allow us to properly have one code base for things like JBoss Logging, JBossXB, JBossAOP, JBossMC with 4.0.x and 5.0.x consuming these projects based on their own versions and branches rather than time consuming and potentially unreliable backports. This would also fix the potential problems with JBoss Cache, Remoting, Seam, etc. compiling over unknown versions of these libraries copied at some point in the past from the JBossAS build. My question is how does this impact the work being done for the Maven build? The last time I looked, only a minimal Maven build was done which was essentially just building the projects that I want to "fix" (fix as in make not broken Scott :-). -- 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=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edge of theMaven cliff
I don't see stabilization happening though as we still have the pending maven move and restructing to have a common module structure and potentially splitting up existing projects to better match the maven ideal. Let's just define how we want commons broken up with Ruel in the loop so he can chase it. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Friday, February 10, 2006 2:47 AM > To: jboss-development@lists.sourceforge.net > Subject: Ongoing build changes: was RE: [JBoss-dev] On the > edge of theMaven cliff > > On a related issue. I really want to bite the bullet on > sorting out the jboss-common dependencies and making more > managable chuncks for standalone projects to eat. > > I've been waiting for the ongoing build changes to stabalise > before doing this in jboss-head. > > This would allow us to properly have one code base for things > like JBoss Logging, JBossXB, JBossAOP, JBossMC with 4.0.x and > 5.0.x consuming these projects based on their own versions > and branches rather than time consuming and potentially > unreliable backports. > > This would also fix the potential problems with JBoss Cache, > Remoting, Seam, etc. compiling over unknown versions of these > libraries copied at some point in the past from the JBossAS build. > > My question is how does this impact the work being done for > the Maven build? The last time I looked, only a minimal Maven > build was done which was essentially just building the > projects that I want to "fix" (fix as in make not broken Scott :-). > -- > > 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=lnk&kid=103432&bid=230486&; > dat=121642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- 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=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edge of theMaven cliff
We already have a task for it http://jira.jboss.com/jira/browse/JBBUILD-58 But I don't believe anybody has really looked at what it will take in general. My comments on the issue in the forums are mainly based on what I remember seeing when I was fixing other things. None of the JIRA tasks contain a link to these discussions. Which is my fault. :-( On Fri, 2006-02-10 at 07:25, Scott M Stark wrote: > I don't see stabilization happening though as we still have the pending > maven move and restructing to have a common module structure and > potentially splitting up existing projects to better match the maven > ideal. Let's just define how we want commons broken up with Ruel in the > loop so he can chase it. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Adrian Brock > > Sent: Friday, February 10, 2006 2:47 AM > > To: jboss-development@lists.sourceforge.net > > Subject: Ongoing build changes: was RE: [JBoss-dev] On the > > edge of theMaven cliff > > > > On a related issue. I really want to bite the bullet on > > sorting out the jboss-common dependencies and making more > > managable chuncks for standalone projects to eat. > > > > I've been waiting for the ongoing build changes to stabalise > > before doing this in jboss-head. > > > > This would allow us to properly have one code base for things > > like JBoss Logging, JBossXB, JBossAOP, JBossMC with 4.0.x and > > 5.0.x consuming these projects based on their own versions > > and branches rather than time consuming and potentially > > unreliable backports. > > > > This would also fix the potential problems with JBoss Cache, > > Remoting, Seam, etc. compiling over unknown versions of these > > libraries copied at some point in the past from the JBossAS build. > > > > My question is how does this impact the work being done for > > the Maven build? The last time I looked, only a minimal Maven > > build was done which was essentially just building the > > projects that I want to "fix" (fix as in make not broken Scott :-). > > -- > > > > 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=lnk&kid=103432&bid=230486&; > > dat=121642 > > ___ > > JBoss-Development mailing list > > JBoss-Development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > --- > 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=lnk&kid3432&bid#0486&dat1642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development -- 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=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edge oftheMaven cliff
Part of the problem is everyone running around trying to get work done on multiple branches while Ruel is trying to baby step new build setups in. I think we need to get to a point where we just say head is going to be refactored and potentially broken for an extended period of time while we refactor it for: - build structure - module coarseness and invalid dependencies (like the server/security issue) - refactoring for integration api introduction The production branches have to remain stable during this. > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 4:43 AM > To: jboss-development@lists.sourceforge.net > Cc: QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On > the edge oftheMaven cliff > > We already have a task for it > http://jira.jboss.com/jira/browse/JBBUILD-58 > > But I don't believe anybody has really looked at what it will > take in general. > > My comments on the issue in the forums are mainly based on > what I remember seeing when I was fixing other things. > > None of the JIRA tasks contain a link to these discussions. > Which is my fault. :-( > --- 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=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On the edgeoftheMaven cliff
I'm not following. aop and xb are no brainer standalone projects that should not be in the jbossas cvs module alias by default. ws and ejb3 probably need to be refactored into standalone modules and a server integration module which can be included in jbossas. I'm not advocating chaos in head because its a good thing. We just need to get to a point where getting this fixed is a priority, and be willing to live with some breakage to get there. If it needs a phased approach, that is fine. What do you suggest? > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 5:15 AM > To: Scott M Stark > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On > the edgeoftheMaven cliff > > Ironically, one of the problems I am trying to solve will be > made worse by this approach. > > That is the number of projects that are really standalone but > are developed in head alongside the application server code. > e.g. AOP, JBossXB, JBossWS, EJB3 > > They need a useable head branch, even if nobody seems to be > paying too much attention to all the testsuite failures. > > I agree with that we shouldn't do anything to the production > branches until we have validated everything in head. > > On Fri, 2006-02-10 at 07:56, Scott M Stark wrote: > > Part of the problem is everyone running around trying to > get work done > > on multiple branches while Ruel is trying to baby step new build > > setups in. I think we need to get to a point where we just > say head is > > going to be refactored and potentially broken for an > extended period > > of time while we refactor it for: > > > > - build structure > > - module coarseness and invalid dependencies (like the > server/security > > issue) > > - refactoring for integration api introduction > > > > The production branches have to remain stable during this. > > > > > -Original Message- > > > From: Adrian Brock > > > Sent: Friday, February 10, 2006 4:43 AM > > > To: jboss-development@lists.sourceforge.net > > > Cc: QA > > > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] > On the edge > > > oftheMaven cliff > > > > > > We already have a task for it > > > http://jira.jboss.com/jira/browse/JBBUILD-58 > > > > > > But I don't believe anybody has really looked at what it > will take > > > in general. > > > > > > My comments on the issue in the forums are mainly based on what I > > > remember seeing when I was fixing other things. > > > > > > None of the JIRA tasks contain a link to these discussions. > > > Which is my fault. :-( > > > > -- > > 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=lnk&kid3432&bid#0486&dat1642 ___ 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=log20060210091944 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/10/2006 09:19:44Time to build: 17 minutes 41 secondsLast changed: 02/09/2006 23:59:00Last log entry: JBREM-316 - changed header apache license where appropriate. Unit Tests: (145) 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 7)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.
Re: Ongoing build changes: was RE: [JBoss-dev] On the edge of the Maven cliff
FYI, we already do this for AOP. Adrian Brock wrote: On a related issue. I really want to bite the bullet on sorting out the jboss-common dependencies and making more managable chuncks for standalone projects to eat. I've been waiting for the ongoing build changes to stabalise before doing this in jboss-head. This would allow us to properly have one code base for things like JBoss Logging, JBossXB, JBossAOP, JBossMC with 4.0.x and 5.0.x consuming these projects based on their own versions and branches rather than time consuming and potentially unreliable backports. This would also fix the potential problems with JBoss Cache, Remoting, Seam, etc. compiling over unknown versions of these libraries copied at some point in the past from the JBossAS build. My question is how does this impact the work being done for the Maven build? The last time I looked, only a minimal Maven build was done which was essentially just building the projects that I want to "fix" (fix as in make not broken Scott :-). -- Bill Burke Chief Architect 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=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Ongoing build changes: was RE: [JBoss-dev] On theedgeoftheMaven cliff
So we need to carve out a "minimal" impact strategy considering projects that today are tied to the jbossas head cvs structure. Maybe we need a nightly snapshot of jbossas in the repository with redefinition of projects like ejb3 to decouple them during the transition. > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 6:46 AM > To: Scott M Stark > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On > theedgeoftheMaven cliff > > On Fri, 2006-02-10 at 08:39, Scott M Stark wrote: > > I'm not following. aop and xb are no brainer standalone > projects that > > should not be in the jbossas cvs module alias by default. > ws and ejb3 > > probably need to be refactored into standalone modules and a server > > integration module which can be included in jbossas. > > > > Yes, because WS and EJB3 use the same codebase to target > different JBossAS releases. Bill already has some > compatibility code to try to deal with this in EJB3. > > > I'm not advocating chaos in head because its a good thing. We just > > need to get to a point where getting this fixed is a > priority, and be > > willing to live with some breakage to get there. If it > needs a phased > > approach, that is fine. What do you suggest? > > > > I was advocating the same JFDI (Just *#&^ Do It) approach > with my "byte with bullet" comment. :-) > > I was just pointing out the potential problems it may cause > people in terms of current development during the transition. > --- 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=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Ongoing build changes: was RE: [JBoss-dev] On the edgeoftheMaven cliff
As for me, we've got to the point when this is a priority. I want to make XB a standalone project ASAP but am not sure how. It depends on JBoss logging at least. Probably, we should define independent projects like, hopefully, the logging and make them standalone first? Scott M Stark wrote: I'm not following. aop and xb are no brainer standalone projects that should not be in the jbossas cvs module alias by default. ws and ejb3 probably need to be refactored into standalone modules and a server integration module which can be included in jbossas. I'm not advocating chaos in head because its a good thing. We just need to get to a point where getting this fixed is a priority, and be willing to live with some breakage to get there. If it needs a phased approach, that is fine. What do you suggest? -Original Message- From: Adrian Brock Sent: Friday, February 10, 2006 5:15 AM To: Scott M Stark Cc: jboss-development@lists.sourceforge.net; QA Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On the edgeoftheMaven cliff Ironically, one of the problems I am trying to solve will be made worse by this approach. That is the number of projects that are really standalone but are developed in head alongside the application server code. e.g. AOP, JBossXB, JBossWS, EJB3 They need a useable head branch, even if nobody seems to be paying too much attention to all the testsuite failures. I agree with that we shouldn't do anything to the production branches until we have validated everything in head. On Fri, 2006-02-10 at 07:56, Scott M Stark wrote: Part of the problem is everyone running around trying to get work done on multiple branches while Ruel is trying to baby step new build setups in. I think we need to get to a point where we just say head is going to be refactored and potentially broken for an extended period of time while we refactor it for: - build structure - module coarseness and invalid dependencies (like the server/security issue) - refactoring for integration api introduction The production branches have to remain stable during this. -Original Message- From: Adrian Brock Sent: Friday, February 10, 2006 4:43 AM To: jboss-development@lists.sourceforge.net Cc: QA Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On the edge oftheMaven cliff We already have a task for it http://jira.jboss.com/jira/browse/JBBUILD-58 But I don't believe anybody has really looked at what it will take in general. My comments on the issue in the forums are mainly based on what I remember seeing when I was fixing other things. None of the JIRA tasks contain a link to these discussions. Which is my fault. :-( -- 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=k&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[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=log20060210100340 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/10/2006 10:03:40Time to build: 74 minutes 8 secondsLast changed: 12/31/2005 20:37:24Last log entry: JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup. Unit Tests: (294) Total Errors and Failures: (13)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.marshall.compress.CompressingMarshallerTestCase(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.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 2038)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/transpor
[JBoss-dev] jboss-3.2-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-jdk-matrix?log=log20060210115431 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:271: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:78: Exit code: 1 See compile_jdk131.log in Build Artifacts for details.Date of build: 02/10/2006 11:54:31Time to build: 11 minutes 24 secondsLast changed: 02/10/2006 09:53:54Last log entry: [JBAS-2795] - Backport the JCA XADS tests from jboss4 Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 2)1.2.2.3modifiedadriantestsuite/imports/sections/jca.xml[JBAS-2795] - Backport the JCA XADS tests from jboss41.3.4.2modifiedadriantestsuite/src/main/org/jboss/test/jca/test/XADSUnitTestCase.java[JBAS-2795] - Backport the JCA XADS tests from jboss4
RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMaven cliff
Let's do that. Do you want to couple this to maven? It would help Ruel I suppose. > -Original Message- > From: Adrian Brock > Sent: Friday, February 10, 2006 9:34 AM > To: Scott M Stark > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: Ongoing build changes: was RE: [JBoss-dev] > OntheedgeoftheMaven cliff > > On Fri, 2006-02-10 at 10:32, Scott M Stark wrote: > > So we need to carve out a "minimal" impact strategy considering > > projects that today are tied to the jbossas head cvs > structure. Maybe > > we need a nightly snapshot of jbossas in the repository with > > redefinition of projects like ejb3 to decouple them during > the transition. > > > > I could certainly create a branch where we could initially > measure the impact of the combined Maven/common changes. > > The main issue being the circularity dependencies across > common which aren't visible with everything in one project. > -- > > 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=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] concurrent-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/concurrent-testsuite?log=log20060210142339 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/10/2006 14:23:39Time to build: 7 minutes 20 seconds Unit Tests: (1707) Total Errors and Failures: (1)testPrivilegedThreadFactory.ExecutorsTest Modifications since last build: (first 50 of 0)
[JBoss-dev] jboss-3.2-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-jdk-matrix?log=log20060210150533 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:271: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:78: Exit code: 1 See compile_jdk131.log in Build Artifacts for details.Date of build: 02/10/2006 15:05:33Time to build: 9 minutes 54 secondsLast changed: 02/10/2006 12:17:09Last log entry: [JBAS-2795] - Remove the property replacement since this already doneat the MBean level. Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 10)1.9.2.15modifiedadrianconnector/src/main/org/jboss/resource/connectionmanager/RARDeployment.java[JBAS-2795] - Remove the property replacement since this already doneat the MBean level.1.4.2.11modifiedadriancommon/src/main/org/jboss/util/Strings.java[JBAS-2795] - Fix the broken String.replace()I never backported the test for this to 3.2.x1.21.2.10modifiedadrianserver/src/main/org/jboss/metadata/MetaData.java[JBAS-2795] - Add metadata methods that do not perform string property replacement1.3.4.3modifiedadriantestsuite/src/main/org/jboss/test/jca/test/XADSUnitTestCase.java[JBAS-2795] - Adapt the test for the 3.2.x name of the connection manager1.4.4.2modifiedadriantestsuite/src/main/org/jboss/test/jca/xads/Test.java[JBAS-2795] - Backport the JCA XADS tests from jboss41.3.4.2modifiedadriantestsuite/src/main/org/jboss/test/jca/xads/TestMBean.java[JBAS-2795] - Backport the JCA XADS tests from jboss41.4.4.2modifiedadriantestsuite/src/main/org/jboss/test/jca/xads/TestXADataSource.java[JBAS-2795] - Backport the JCA XADS tests from jboss41.3.8.2modifiedadriantestsuite/src/resources/jca/xads/test-xa-ds.xml[JBAS-2795] - Backport the JCA XADS tests from jboss41.2.2.3modifiedadriantestsuite/imports/sections/jca.xml[JBAS-2795] - Backport the JCA XADS tests from jboss41.3.4.2modifiedadriantestsuite/src/main/org/jboss/test/jca/test/XADSUnitTestCase.java[JBAS-2795] - Backport the JCA XADS tests from jboss4
[JBoss-dev] jboss-head-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060210161905 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details.Date of build: 02/10/2006 16:19:05Time to build: 33 minutes 9 secondsLast changed: 02/10/2006 16:11:18Last log entry: Rever 1.91 apply patch from Chris Laprun Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 1)1.92modifiedjgreenewebservice/build.xmlRever 1.91 apply patch from Chris Laprun
[JBoss-dev] jboss-head-jdk-matrix build.1393 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060210171839Lbuild.1393 BUILD COMPLETE - build.1393Date of build: 02/10/2006 17:18:39Time to build: 34 minutes 50 secondsLast changed: 02/10/2006 17:08:40Last log entry: fix build Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 2)1.93modifiedjgreenewebservice/build.xmlfix build1.92modifiedjgreenewebservice/build.xmlRever 1.91 apply patch from Chris Laprun
[JBoss-dev] ejb3-4.0-testsuite Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060211003634 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details.Date of build: 02/11/2006 00:36:34Time to build: 29 minutes 19 secondsLast changed: 12/31/2005 16:46:08Last log entry: call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 3660)1.3modifiedbillsrc/test/org/jboss/ejb3/test/tableperinheritance/unit/EntityUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.7modifiedbillsrc/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.6modifiedbillsrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaEJBs and Persistence can now be within a .jar file1.3modifiedbillsrc/test/org/jboss/ejb3/test/xmlcfg/unit/EntityUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.4modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/Dao.javaapplication-exception support1.7modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DaoBean.javaapplication-exception support1.1addedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DeploymentDescriptorAppException.javabranches: 1.1.2;application-exception support1.1addedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DeploymentDescriptorCheckedRollbackException.javabranches: 1.1.2;application-exception support1.5modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaapplication-exception support1.2modifiedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/QueueTestMDB.javabranches: 1.2.2;activateConfig to activationConfig1.2modifiedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/TopicTestMDB.javabranches: 1.2.2;activateConfig to activationConfig1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/unit/EmbeddedEjb3TestCase.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/Customer.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAOBean.javabranches: 1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAOLocal.javabranches: 1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAORemote.javabranches: 1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/EmbeddedEJB3.jsptest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/JndiTest.jsptest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/QueueTestMDB.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/TopicTestMDB.javatest for embedded EJB3 in WLS1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/Customer.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/EntityTest.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/EntityTestBean.javaUpdate the jboss LGPL headers1.4modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTester.javaUpdate the jboss LGPL headers1.9modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTesterBean.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTesterBean21.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/AnnotatedAppException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/AppException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/CheckedRollbackException.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/Dao.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/DaoBean.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/NoRollbackRemoteException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/NoRollbackRuntimeException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/RollbackRemoteException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/RollbackRuntimeException.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/SimpleEntity.javaUpdate the jboss LGPL headers1.4m
