Ah, so really it's gotten worse now that I changed it as the jar target is always getting run. We could re-add the warning but this time to ask that the jar target be run before. Would that be an option? When I changed the test target to not depend on the dist etc target, I did it for all these reasons. It cut test time dramatically. Stuff is getting called multiple time - "generate-config-model" was getting called 3 or 4 times. Of course the text book answer to this problem is to sort that out, but the build is a beast at this stage, with a hornets nest of dependencies - I'd be afraid to make any major changes to it. Ever hear of the "Shotgun Surgery" code smell ;-) Role on maven shmaven ;-) Daniel Bevenius wrote: >> I see it when I run "ant clean dist test". Should these be >> integration tests perhaps, or has the build changed to run the >> integration tests under the general "test" build target? >> >> > I updated the 'test' target, (after the discussion in the "build question" googlegroups thread) so that it depends on the jar target which means 'ant clean test' should be all that is needed to run the tests. Running dist will actually run som stuff twice, like generate-config-model. > > Running 'ant dist test' is now the same as running the default target. > > But the build does take quite some time for me...like 7 min or so. I think that a lot of jar targets are run regardless of changes to classes. The generate-config-model will always run even if the schemas are unmodified. This will change when we move to jabx though. > > /Daniel > > > > > > > "ant clean dist test" > > I'm running clean, dist, test within Eclipse. Took 21 minutes to > build everything for me ;-) > > I'll do another update to make sure nothing changed since yesterday > afternoon, when I did my last one. > > I hope the test rule *does not* run the integration tests ;-) > > Mark. > > > On 27 Jun 2007, at 10:27, Tom Fennelly wrote: > > > >> What build rule are you using ;-) ? >> >> I see it when I run "ant clean dist test". Should these be >> integration tests perhaps, or has the build changed to run the >> integration tests under the general "test" build target? >> >> T. >> >> >> Mark Little wrote: >> >> >>> I did an update and a build, but didn't see this. What build rule >>> were you using? >>> >>> Mark. >>> >>> >>> On 26 Jun 2007, at 16:54, Kurt T Stam wrote: >>> >>> >>> >>>> Anyone getting this? What do I do to fix this? >>>> >>>> [java] [junit] Testcase: >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>> tTest >>>> took 0 sec >>>> [java] [junit] Caused an ERROR >>>> [java] [junit] >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSyste >>>> mStrategyException: >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>> cheException: >>>> org.jgroups.ChannelException: failed to start protocol stack >>>> [java] [junit] org.jboss.soa.esb.ConfigurationException: >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSyste >>>> mStrategyException: >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>> cheException: >>>> org.jgroups.ChannelException: failed to start protocol stack >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListener.cr >>>> eateRemoteFileSystemStrategy(ReadOnlyRemoteGatewayListener.java:222) >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListener.<i >>>> nit>(ReadOnlyRemoteGatewayListener.java:83) >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>> tTest.createRemoteGatewayListener >>>> (ReadOnlyRemoteGatewayListenerUnitTest.java:212) >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>> tTest.classSetup(ReadOnlyRemoteGatewayListenerUnitTest.java:76) >>>> [java] [junit] at >>>> org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod >>>> (BeforeAndAfterRunner.java:74) >>>> [java] [junit] at >>>> org.junit.internal.runners.BeforeAndAfterRunner.runBefores >>>> (BeforeAndAfterRunner.java:50) >>>> [java] [junit] at >>>> org.junit.internal.runners.BeforeAndAfterRunner.runProtected >>>> (BeforeAndAfterRunner.java:33) >>>> [java] [junit] at >>>> org.junit.internal.runners.TestClassRunner.run >>>> (TestClassRunner.java:52) >>>> [java] [junit] at >>>> junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32) >>>> [java] [junit] Caused by: >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSyste >>>> mStrategyException: >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>> cheException: >>>> org.jgroups.ChannelException: failed to start protocol stack >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.ReadOnlyRemoteF >>>> ileSystemStrategy.init(ReadOnlyRemoteFileSystemStrategy.java:63) >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListener.cr >>>> eateRemoteFileSystemStrategy(ReadOnlyRemoteGatewayListener.java:205) >>>> [java] [junit] ... 15 more >>>> [java] [junit] Caused by: >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>> cheException: >>>> org.jgroups.ChannelException: failed to start protocol stack >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>> che.start(FtpFileCache.java:135) >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.ReadOnlyRemoteF >>>> ileSystemStrategy.init(ReadOnlyRemoteFileSystemStrategy.java:59) >>>> [java] [junit] ... 16 more >>>> [java] [junit] Caused by: org.jgroups.ChannelException: >>>> failed to >>>> start protocol stack >>>> [java] [junit] at org.jgroups.JChannel.connect >>>> (JChannel.java:389) >>>> [java] [junit] at >>>> org.jboss.cache.TreeCache.startService(TreeCache.java:1263) >>>> [java] [junit] at >>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>> che.start(FtpFileCache.java:130) >>>> [java] [junit] ... 17 more >>>> [java] [junit] Caused by: java.lang.Exception: exception >>>> caused by >>>> UDP.start() >>>> [java] [junit] at >>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:582) >>>> [java] [junit] at >>>> org.jgroups.stack.DownHandler.run(Protocol.java:118) >>>> [java] [junit] Caused by: java.lang.Exception: problem creating >>>> sockets (bind_addr=localhost/127.0.0.1, mcast_addr=228.1.2.3:48866) >>>> [java] [junit] at org.jgroups.protocols.UDP.start >>>> (UDP.java:372) >>>> [java] [junit] at >>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:571) >>>> [java] [junit] ... 1 more >>>> [java] [junit] Caused by: java.net.SocketException: bad >>>> argument >>>> for IP_MULTICAST_IF2: No IP addresses bound to interface >>>> [java] [junit] at >>>> java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) >>>> [java] [junit] at >>>> java.net.PlainDatagramSocketImpl.setOption >>>> (PlainDatagramSocketImpl.java:299) >>>> [java] [junit] at >>>> java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java: >>>> 502) >>>> [java] [junit] at >>>> org.jgroups.protocols.UDP.createSockets(UDP.java:490) >>>> [java] [junit] at org.jgroups.protocols.UDP.start >>>> (UDP.java:367) >>>> [java] [junit] ... 2 more >>>> [java] BUILD FAILED >>>> [java] C:\cygwin\home\kstam\dev\jbossesb\product\build.xml: >>>> 131: The >>>> following error occurred while executing this line: >>>> [java] C:\cygwin\home\kstam\dev\jbossesb\product\build.xml: >>>> 141: The >>>> following error occurred while executing this line: >>>> [java] >>>> C:\cygwin\home\kstam\dev\jbossesb\product\rosetta\build.xml:87: The >>>> following error occurred while executing this line: >>>> [java] >>>> C:\cygwin\home\kstam\dev\jbossesb\product\rosetta\tests\build.xml: >>>> 82: >>>> The following error occurred while executing this line: >>>> [java] >>>> C:\cygwin\home\kstam\dev\jbossesb\product\rosetta\tests\build.xml: >>>> 109: >>>> Test >>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>> tTest >>>> failed >>>> [java] Total time: 3 minutes 57 seconds >>>> >>>> BUILD FAILED >>>> C:\cygwin\home\kstam\dev\jbossesb\product\build.xml:420: The >>>> following >>>> error occurred while executing this line: >>>> C:\cygwin\home\kstam\dev\jbossesb\product\build.xml:87: Java >>>> returned: 1 >>>> >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>> >>>> >>> ---- >>> >>> Mark Little >>> mlittle(a)redhat.com <mailto:mlittle@redhat.com> >>> >>> JBoss, a Division of Red Hat >>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 >>> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >>> Registered in UK and Wales under Company Registration No. 3798903 >>> Directors: Michael Cunningham (USA), Charlie Peters (USA) and >>> David Owens (Ireland) >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> _______________________________________________ >>> esb-dev mailing list >>> esb-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> >>> >>> >> -- >> Red Hat: >> Registered Address: Red Hat Ltd, Brian O' Donnell and Partners, 62 >> Merrion Square, Dublin 2, Ireland. >> Registered in the Companies Registration Office, Parnell House, 14 >> Parnell Square, Dublin 1, Ireland, at No. 304873 >> Directors: Charlie Peters (USA), Michael Cunningham (USA). David >> Owens, Brendan Lane >> >> >> > ---- > > Mark Little > mlittle(a)redhat.com > > JBoss, a Division of Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, > SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA) and David > Owens (Ireland) > > > > > > >

+1 making the build actually use dependency checking would be major time saver. Now that we only have 1/3 of the build left (just rosetta) that should not be that big a deal. Also I still like running of our embedded ftp server just like we do for the database (hsqldb). It would make debugging problems like these so much easier, as everyone runs the same build (nothing environment specific). I've seen this over and over again in the past. my 2 cents. --Kurt Tom Fennelly wrote: > All things considered, that's what I'd personally go for but I'd guess > there might be objections to that on grounds of principal :-) > > Daniel Bevenius wrote: > >> Ah, so really it's gotten worse now that I changed it as the jar >> target is always getting run. We could re-add the warning but this >> time to ask that the jar target be run before. >> >> Would that be an option? >> >> >> When I changed the test target to not depend on the dist etc target, >> I did it for all these reasons. It cut test time dramatically. >> Stuff is getting called multiple time - "generate-config-model" was >> getting called 3 or 4 times. Of course the text book answer to this >> problem is to sort that out, but the build is a beast at this stage, >> with a hornets nest of dependencies - I'd be afraid to make any major >> changes to it. Ever hear of the "Shotgun Surgery" code smell ;-) >> >> Role on maven shmaven ;-) >> >> >> Daniel Bevenius wrote: >> >> >>>> I see it when I run "ant clean dist test". Should these be >>>> integration tests perhaps, or has the build changed to run the >>>> integration tests under the general "test" build target? >>>> >>>> >>> I updated the 'test' target, (after the discussion in the "build >>> question" googlegroups thread) so that it depends on the jar target >>> which means 'ant clean test' should be all that is needed to run the >>> tests. Running dist will actually run som stuff twice, like >>> generate-config-model. >>> >>> Running 'ant dist test' is now the same as running the default target. >>> But the build does take quite some time for me...like 7 min or so. I >>> think that a lot of jar targets are run regardless of changes to >>> classes. The generate-config-model will always run even if the >>> schemas are unmodified. This will change when we move to jabx though. >>> /Daniel >>> >>> >>> >>> >>> >>> >>> "ant clean dist test" >>> >>> I'm running clean, dist, test within Eclipse. Took 21 minutes to >>> build everything for me ;-) >>> >>> I'll do another update to make sure nothing changed since yesterday >>> afternoon, when I did my last one. >>> >>> I hope the test rule *does not* run the integration tests ;-) >>> >>> Mark. >>> >>> >>> On 27 Jun 2007, at 10:27, Tom Fennelly wrote: >>> >>> >>> >>>> What build rule are you using ;-) ? >>>> >>>> I see it when I run "ant clean dist test". Should these be >>>> integration tests perhaps, or has the build changed to run the >>>> integration tests under the general "test" build target? >>>> >>>> T. >>>> >>>> >>>> Mark Little wrote: >>>> >>>> >>>>> I did an update and a build, but didn't see this. What build rule >>>>> were you using? >>>>> >>>>> Mark. >>>>> >>>>> >>>>> On 26 Jun 2007, at 16:54, Kurt T Stam wrote: >>>>> >>>>> >>>>> >>>>>> Anyone getting this? What do I do to fix this? >>>>>> >>>>>> [java] [junit] Testcase: >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>>>> tTest >>>>>> took 0 sec >>>>>> [java] [junit] Caused an ERROR >>>>>> [java] [junit] >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSyste >>>>>> mStrategyException: >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>>>> cheException: >>>>>> org.jgroups.ChannelException: failed to start protocol stack >>>>>> [java] [junit] org.jboss.soa.esb.ConfigurationException: >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSyste >>>>>> mStrategyException: >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>>>> cheException: >>>>>> org.jgroups.ChannelException: failed to start protocol stack >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListener.cr >>>>>> eateRemoteFileSystemStrategy(ReadOnlyRemoteGatewayListener.java:222) >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListener.<i >>>>>> nit>(ReadOnlyRemoteGatewayListener.java:83) >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>>>> tTest.createRemoteGatewayListener >>>>>> (ReadOnlyRemoteGatewayListenerUnitTest.java:212) >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>>>> tTest.classSetup(ReadOnlyRemoteGatewayListenerUnitTest.java:76) >>>>>> [java] [junit] at >>>>>> org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod >>>>>> (BeforeAndAfterRunner.java:74) >>>>>> [java] [junit] at >>>>>> org.junit.internal.runners.BeforeAndAfterRunner.runBefores >>>>>> (BeforeAndAfterRunner.java:50) >>>>>> [java] [junit] at >>>>>> org.junit.internal.runners.BeforeAndAfterRunner.runProtected >>>>>> (BeforeAndAfterRunner.java:33) >>>>>> [java] [junit] at >>>>>> org.junit.internal.runners.TestClassRunner.run >>>>>> (TestClassRunner.java:52) >>>>>> [java] [junit] at >>>>>> junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32) >>>>>> [java] [junit] Caused by: >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSyste >>>>>> mStrategyException: >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>>>> cheException: >>>>>> org.jgroups.ChannelException: failed to start protocol stack >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.ReadOnlyRemoteF >>>>>> ileSystemStrategy.init(ReadOnlyRemoteFileSystemStrategy.java:63) >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListener.cr >>>>>> eateRemoteFileSystemStrategy(ReadOnlyRemoteGatewayListener.java:205) >>>>>> [java] [junit] ... 15 more >>>>>> [java] [junit] Caused by: >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>>>> cheException: >>>>>> org.jgroups.ChannelException: failed to start protocol stack >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>>>> che.start(FtpFileCache.java:135) >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.ReadOnlyRemoteF >>>>>> ileSystemStrategy.init(ReadOnlyRemoteFileSystemStrategy.java:59) >>>>>> [java] [junit] ... 16 more >>>>>> [java] [junit] Caused by: org.jgroups.ChannelException: >>>>>> failed to >>>>>> start protocol stack >>>>>> [java] [junit] at org.jgroups.JChannel.connect >>>>>> (JChannel.java:389) >>>>>> [java] [junit] at >>>>>> org.jboss.cache.TreeCache.startService(TreeCache.java:1263) >>>>>> [java] [junit] at >>>>>> org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.FtpFileCa >>>>>> che.start(FtpFileCache.java:130) >>>>>> [java] [junit] ... 17 more >>>>>> [java] [junit] Caused by: java.lang.Exception: exception >>>>>> caused by >>>>>> UDP.start() >>>>>> [java] [junit] at >>>>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:582) >>>>>> [java] [junit] at >>>>>> org.jgroups.stack.DownHandler.run(Protocol.java:118) >>>>>> [java] [junit] Caused by: java.lang.Exception: problem creating >>>>>> sockets (bind_addr=localhost/127.0.0.1, mcast_addr=228.1.2.3:48866) >>>>>> [java] [junit] at org.jgroups.protocols.UDP.start >>>>>> (UDP.java:372) >>>>>> [java] [junit] at >>>>>> org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:571) >>>>>> [java] [junit] ... 1 more >>>>>> [java] [junit] Caused by: java.net.SocketException: bad >>>>>> argument >>>>>> for IP_MULTICAST_IF2: No IP addresses bound to interface >>>>>> [java] [junit] at >>>>>> java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) >>>>>> [java] [junit] at >>>>>> java.net.PlainDatagramSocketImpl.setOption >>>>>> (PlainDatagramSocketImpl.java:299) >>>>>> [java] [junit] at >>>>>> java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java: >>>>>> 502) >>>>>> [java] [junit] at >>>>>> org.jgroups.protocols.UDP.createSockets(UDP.java:490) >>>>>> [java] [junit] at org.jgroups.protocols.UDP.start >>>>>> (UDP.java:367) >>>>>> [java] [junit] ... 2 more >>>>>> [java] BUILD FAILED >>>>>> [java] C:\cygwin\home\kstam\dev\jbossesb\product\build.xml: >>>>>> 131: The >>>>>> following error occurred while executing this line: >>>>>> [java] C:\cygwin\home\kstam\dev\jbossesb\product\build.xml: >>>>>> 141: The >>>>>> following error occurred while executing this line: >>>>>> [java] >>>>>> C:\cygwin\home\kstam\dev\jbossesb\product\rosetta\build.xml:87: The >>>>>> following error occurred while executing this line: >>>>>> [java] >>>>>> C:\cygwin\home\kstam\dev\jbossesb\product\rosetta\tests\build.xml: >>>>>> 82: >>>>>> The following error occurred while executing this line: >>>>>> [java] >>>>>> C:\cygwin\home\kstam\dev\jbossesb\product\rosetta\tests\build.xml: >>>>>> 109: >>>>>> Test >>>>>> org.jboss.soa.esb.listeners.gateway.ReadOnlyRemoteGatewayListenerUni >>>>>> tTest >>>>>> failed >>>>>> [java] Total time: 3 minutes 57 seconds >>>>>> >>>>>> BUILD FAILED >>>>>> C:\cygwin\home\kstam\dev\jbossesb\product\build.xml:420: The >>>>>> following >>>>>> error occurred while executing this line: >>>>>> C:\cygwin\home\kstam\dev\jbossesb\product\build.xml:87: Java >>>>>> returned: 1 >>>>>> >>>>>> _______________________________________________ >>>>>> esb-dev mailing list >>>>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>>> >>>>>> >>>>> ---- >>>>> >>>>> Mark Little >>>>> mlittle(a)redhat.com <mailto:mlittle@redhat.com> >>>>> >>>>> JBoss, a Division of Red Hat >>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 >>>>> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >>>>> Registered in UK and Wales under Company Registration No. 3798903 >>>>> Directors: Michael Cunningham (USA), Charlie Peters (USA) and >>>>> David Owens (Ireland) >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> --- >>>>> >>>>> _______________________________________________ >>>>> esb-dev mailing list >>>>> esb-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>>>> >>>>> >>>>> >>>> -- >>>> Red Hat: >>>> Registered Address: Red Hat Ltd, Brian O' Donnell and Partners, 62 >>>> Merrion Square, Dublin 2, Ireland. >>>> Registered in the Companies Registration Office, Parnell House, 14 >>>> Parnell Square, Dublin 1, Ireland, at No. 304873 >>>> Directors: Charlie Peters (USA), Michael Cunningham (USA). David >>>> Owens, Brendan Lane >>>> >>>> >>>> >>> ---- >>> >>> Mark Little >>> mlittle(a)redhat.com >>> >>> JBoss, a Division of Red Hat >>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod >>> Street, Windsor, Berkshire, >>> SI4 1TE, United Kingdom. >>> Registered in UK and Wales under Company Registration No. 3798903 >>> Directors: Michael Cunningham (USA), Charlie Peters (USA) and David >>> Owens (Ireland) >>> >>> >>> >>> >>> >>> >>> >> >>

Tom Fennelly wrote: > Kurt just pointed something out to me re those "runant" macros. Are > these at the root of our problem re builds taking forever because > targets are running multiple times? I saw these a few weeks back and > was wondering why they were necessary but was afraid to ask at the time > :-) Well, anyone know what these are about? > Yes, the runant macros are there to make sure that the build has the correct classpath (notably including junit) so that you can just run ant and 'it will work (tm)'. It is only supposed to be used in the public targets so dependencies should not be using those. Kev

BTW, including the junit.jar in the <junit> target classpath and forking <junit> didn't sort this?

Sure, but a task running <junit> could be called using runant, rather than everything including compilation etc. Surely there's a way of isolating it a bit :-)

Only once ;-):

As I said, I will go through it tonight and make sure it is correct :)

I'd +1 on fixing this up if it can dramatically reduce build times. Any idea what we might get it down to? I seem to recall it used to take about 7 minutes on my "old" box :-(

If we were going to spend time on the build scripts, I'd vote for looking at ways to simplify them altogether rather than patching them more with timers etc. I think once we simplify them, we'll be in a better position to sort out issues around making it run quicker. The product/build.xml has 33 targets in it >:o . As I see it, the whole thing is overly hierarchical with build.xml files at nearly every level + separate build.xml files for testing etc. Many of the property names are so long that it becomes very difficult to distinguish between them. I think we're overly fixated with trying to make the build scripts super intelligent ala "I want to be able to run any target and have the build figure out what else needs to be run" resulting in every target being dependent on every other target up and down the build. Sorry for going on a bit. It's just that our build is something that drives me bats. KISS :-* T. Mark Little wrote: > I'd +1 on fixing this up if it can dramatically reduce build > times. Any idea what we might get it down to? I seem to recall it > used to take about 7 minutes on my "old" box :-( > > Mark. > > > On 28 Jun 2007, at 11:55, Kevin Conner wrote: > >> Kevin Conner wrote: >>> As I said, I will go through it tonight and make sure it is >>> correct :) >> >> I went through the build files and tidied them up but this is not >> the >> reason for the long build time. It appears that a number of >> targets are >> being called more than once, caused by the build files traversing >> their >> targets horizontally and vertically. >> >> There are a number of tasks which can handle this, javac springs to >> mind, but the majority of them do not. The normal way of >> handling these >> types of issue is to create a timestamp file when the particular >> target >> executes. This timestamp file can then be used, in conjunction >> with the >> target requirements, to determine whether the target needs to be >> executed. >> >> This could be used to shorten the build cycle, especially for repeat >> invocations (i.e. rerunning tests). >> >> Does anyone feel that this is something worth implementing at >> this stage? >> >> Kev >> >> P.S. I am sharing wireless atm so may not get any replies until >> tomorrow :) >> >> -- >> JBoss, a Division of Red Hat >> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod >> Street, Windsor, Berkshire, >> SI4 1TE, United Kingdom. >> Registered in UK and Wales under Company Registration No. 3798903 >> Directors: Michael Cunningham (USA), Charlie Peters (USA) and David >> Owens (Ireland) >> _______________________________________________ >> esb-dev mailing list >> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/esb-dev > > ---- > > Mark Little > mlittle(a)redhat.com <mailto:mlittle@redhat.com> > > JBoss, a Division of Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 > Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA) and > David Owens (Ireland) > > > > -- Red Hat: Registered Address: Red Hat Ltd, Brian O' Donnell and Partners, 62 Merrion Square, Dublin 2, Ireland. Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, at No. 304873 Directors: Charlie Peters (USA), Michael Cunningham (USA). David Owens, Brendan Lane

Mark Little wrote: > The problem with revamping is that you never know where to stop or > you could be opening up a can of worms. I think Kev hinted at this > yesterday. Shotgun Surgery - that was moi

> So although I'd be +1 to fixing these if it makes an appreciable > difference to build time, I'd -1 if that means spending the next > week or so working on build scripts and the knock-on effect that > has on everyone else while it's going on and after it's "complete". Know what you mean... I'd leave it altogether until after the 4.2 release, at which point you'll probably want to leave it forever ;-) Personally I feel there's only one real solution to this and that's a rework, but I'm sure others will disagree and push for more patching :-)

> > I can put up with a 21 minute build. If you guys are at the 7 > minute level (new machines ;-) then I'm not sure it's a big impact > on what you're doing in terms of build time. It's a pain in the ass, but ... role on 5.0 and maven2 :-)

> > Mark. > > > On 28 Jun 2007, at 12:22, Tom Fennelly wrote: > >> If we were going to spend time on the build scripts, I'd vote for >> looking at ways to simplify them altogether rather than patching >> them more with timers etc. I think once we simplify them, we'll >> be in a better position to sort out issues around making it run >> quicker. >> >> The product/build.xml has 33 targets in it >:o . As I see it, >> the whole thing is overly hierarchical with build.xml files at >> nearly every level + separate build.xml files for testing etc. >> Many of the property names are so long that it becomes very >> difficult to distinguish between them. I think we're overly >> fixated with trying to make the build scripts super intelligent >> ala "I want to be able to run any target and have the build >> figure out what else needs to be run" resulting in every target >> being dependent on every other target up and down the build. >> >> Sorry for going on a bit. It's just that our build is something >> that drives me bats. >> >> KISS :-* >> >> T. >> >> >> Mark Little wrote: >>> I'd +1 on fixing this up if it can dramatically reduce build >>> times. Any idea what we might get it down to? I seem to recall >>> it used to take about 7 minutes on my "old" box :-( >>> >>> Mark. >>> >>> >>> On 28 Jun 2007, at 11:55, Kevin Conner wrote: >>> >>>> Kevin Conner wrote: >>>>> As I said, I will go through it tonight and make sure it is >>>>> correct :) >>>> >>>> I went through the build files and tidied them up but this is >>>> not the >>>> reason for the long build time. It appears that a number of >>>> targets are >>>> being called more than once, caused by the build files >>>> traversing their >>>> targets horizontally and vertically. >>>> >>>> There are a number of tasks which can handle this, javac >>>> springs to >>>> mind, but the majority of them do not. The normal way of >>>> handling these >>>> types of issue is to create a timestamp file when the >>>> particular target >>>> executes. This timestamp file can then be used, in conjunction >>>> with the >>>> target requirements, to determine whether the target needs to >>>> be executed. >>>> >>>> This could be used to shorten the build cycle, especially for >>>> repeat >>>> invocations (i.e. rerunning tests). >>>> >>>> Does anyone feel that this is something worth implementing at >>>> this stage? >>>> >>>> Kev >>>> >>>> P.S. I am sharing wireless atm so may not get any replies until >>>> tomorrow :) >>>> >>>> -- >>>> JBoss, a Division of Red Hat >>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 >>>> Peascod >>>> Street, Windsor, Berkshire, >>>> SI4 1TE, United Kingdom. >>>> Registered in UK and Wales under Company Registration No. 3798903 >>>> Directors: Michael Cunningham (USA), Charlie Peters (USA) and >>>> David >>>> Owens (Ireland) >>>> _______________________________________________ >>>> esb-dev mailing list >>>> esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/esb-dev >>> >>> ---- >>> >>> Mark Little >>> mlittle(a)redhat.com <mailto:mlittle@redhat.com> >>> >>> JBoss, a Division of Red Hat >>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 >>> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >>> Registered in UK and Wales under Company Registration No. >>> 3798903 Directors: Michael Cunningham (USA), Charlie Peters >>> (USA) and David Owens (Ireland) >>> >>> >>> >>> >> >> -- >> Red Hat: >> Registered Address: Red Hat Ltd, Brian O' Donnell and Partners, >> 62 Merrion Square, Dublin 2, Ireland. >> Registered in the Companies Registration Office, Parnell House, >> 14 Parnell Square, Dublin 1, Ireland, at No. 304873 >> Directors: Charlie Peters (USA), Michael Cunningham (USA). David >> Owens, Brendan Lane >> > > ---- > > Mark Little > mlittle(a)redhat.com <mailto:mlittle@redhat.com> > > JBoss, a Division of Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 > Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA) and > David Owens (Ireland) > > > > -- Red Hat: Registered Address: Red Hat Ltd, Brian O' Donnell and Partners, 62 Merrion Square, Dublin 2, Ireland. Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, at No. 304873 Directors: Charlie Peters (USA), Michael Cunningham (USA). David Owens, Brendan Lane

> I can put up with a 21 minute build. If you guys are at the 7 minute > level (new machines ;-) then I'm not sure it's a big impact on what > you're doing in terms of build time. 21 mins? Seriously? Kev -- JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Tom Fennelly wrote: > If we were going to spend time on the build scripts, I'd vote for > looking at ways to simplify them altogether rather than patching them > more with timers etc. I think once we simplify them, we'll be in a > better position to sort out issues around making it run quicker. If we had the time to spend then I would agree, in fact my vote would be a move to maven ;) As things stand, an issue has been raised over the time the build takes to run. We can choose to rewrite it totally or just patch it up but our time is the main constraint. We may be able to put a 'band aid' on the current build to alleviate this issue without spending too much time. > The product/build.xml has 33 targets in it >:o . As I see it, the > whole > thing is overly hierarchical with build.xml files at nearly every > level > + separate build.xml files for testing etc. Many of the property > names > are so long that it becomes very difficult to distinguish between > them. > I think we're overly fixated with trying to make the build scripts > super > intelligent ala "I want to be able to run any target and have the > build > figure out what else needs to be run" resulting in every target being > dependent on every other target up and down the build. Having the build files being hierarchical is not really the issue, it is just an artifact of the way the codebase has evolved. Having a common base build file would also alleviate the issue of having different build files for tests etc and make it almost irrelevant. > Sorry for going on a bit. It's just that our build is something that > drives me bats. > > KISS :-* +1 Kev -- JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

> My son (4) cut his hand last Saturday after a fall off his bike. I had a pain in the behind sticking plasters on it. He was never happy and the plaster never seemed to sort the real problem out. Can't we just leave it if we can't sort it properly at this stage? I'm fed up with band aids :-)

On 28 Jun 2007, at 12:45, Tom Fennelly wrote: >> > My son (4) cut his hand last Saturday after a fall off his bike. I > had a pain in the behind sticking plasters on it. He was never happy > and the plaster never seemed to sort the real problem out. > Can't we just leave it if we can't sort it properly at this stage? > I'm fed up with band aids :-) Couldn't you convince him to try maven ;-)? Mark. ---- Mark Little mlittle(a)redhat.com <mailto:mlittle@redhat.com> JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)