RE: [JBoss-dev] Build System... any ideas
Do you know any folks with Ant rw? --jason On Fri, 4 Oct 2002, Matt Munz wrote: David, As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. Yeah, there's a lot of paranoid classes in there. If we show them that something useful can be done by opening up more of the ant core to the public interface, however, I think they'll fold it into the code base. It's not like it needs that much tweaking. I think that they are mainly concerned about not falling into the same pitfalls as make did. As long as it's clear that we're not trying to change ANT into something baroque and complex and contorted, I think they'll be alright. Plus, opening up the core API is good for IDE integration -- one of their goals. Of course, this assumes that politics is not an issue... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, October 04, 2002 8:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Probably not:-) My idea involved a complete rewrite of ant as a bunch of mbeans, using as much jmx functionality as possible. This was based on the observation that the ant team seems to struggle a lot with classloading and questions of exactly how detyped their interfaces should be, plus dynamic extensions. Since these are what jmx is so good at, I thought building ant on jmx made a lot of sense. I think perhaps what marc is talking about is to run ant within jboss as an mbean. Back in February I spent a week or so trying to make this work (so we could have an xdoclet deployer, drop your source code in and it gets xdoclet-ized, compiled, and deployed) but I could not work around the ant classloaders to make anything work. (as I recall, really basic ant scripts worked but xdoclet did not at all). As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. david jencks On 2002.10.04 19:01:58 -0400 Jason Dillon wrote: Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using
RE: [JBoss-dev] Build System... any ideas
Okay, sounds interesting. Do you have an concreate ideas on a design for such a beast? --jason On Fri, 4 Oct 2002, Matt Munz wrote: Can you explain the Ant MBean thing to me please. Here's the way I see it. ANT features: core system composed of engine + modules engine loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every Task in ANT is invoked via Task.execute() XML definition allows flexible definition of Tasks (ANT XML) JMX features: core system composed of server + modules server loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every MBean in JMX is invoked via MBean.invoke() XML definition allows flexible definition of MBeans (XMBean XML) So much overlap. For many of these things, JMX simply does the job better. Ever try to add a plugins feature to an application, so that your clients can add on their own extensions? After I found out about JMX, it was like a light went on -- this is the way to do it... What we're all trying to do -- build robust applications out of building blocks, self-consistent units. What ant has going for it is the functionality. All the cross-platform wrinkles worked out -- the javac task just works. What JMX has going for it is the architecture -- powerful, clear, classloading figured out, dependable, flexible. If we can put these together, we'll have many benefits for both projects. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Friday, October 04, 2002 7:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build
RE: [JBoss-dev] Build System... any ideas
Okay, sounds interesting. Do you have an concreate ideas on a design for such a beast? Nope, just broad generalizations ;) David's idea for a re-write (refactoring) makes sense to me if done incrementally. Off the top of my head... I think a good first step would be to wrap the ant engine in an MBean, allowing programmatic access to the engine to load and run tasks. Once ANT can live in the JMX server, the ANT architecture can be replaced with its JMX equivalent, step by step. Next I'd find a way to wrap an MBean in a Task proxy, and wrap a Task in an MBean. This would allow Tasks in the JMX server and MBeans in the ant environment. Then I'd replace ANT's classloading with JMX classloading. At some point, Task would go away and be replaced with MBeans. Work done by the Task interface and introspection could be accomplished with MBean metadata, I.e. the execute() method for the Javac MBean is compile(). At some point, ANT XML could simply become a way to specify an order in which MBeans are instantiated, registered, and invoked to accomplish the goals for a given target. Each one of these steps has a lot of benefits, and I think the whole shebang is a large project. Something that I find very interesting and valueable, but not necessary for the work I'm doing now :( I'm glad to see your interest in this -- I hope some of this helps. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Saturday, October 05, 2002 3:42 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Okay, sounds interesting. Do you have an concreate ideas on a design for such a beast? --jason On Fri, 4 Oct 2002, Matt Munz wrote: Can you explain the Ant MBean thing to me please. Here's the way I see it. ANT features: core system composed of engine + modules engine loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every Task in ANT is invoked via Task.execute() XML definition allows flexible definition of Tasks (ANT XML) JMX features: core system composed of server + modules server loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every MBean in JMX is invoked via MBean.invoke() XML definition allows flexible definition of MBeans (XMBean XML) So much overlap. For many of these things, JMX simply does the job better. Ever try to add a plugins feature to an application, so that your clients can add on their own extensions? After I found out about JMX, it was like a light went on -- this is the way to do it... What we're all trying to do -- build robust applications out of building blocks, self-consistent units. What ant has going for it is the functionality. All the cross-platform wrinkles worked out -- the javac task just works. What JMX has going for it is the architecture -- powerful, clear, classloading figured out, dependable, flexible. If we can put these together, we'll have many benefits for both projects. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Friday, October 04, 2002 7:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project
RE: [JBoss-dev] Build System... any ideas
Thanks. I am convinced that this is the way to go... now I just need to find how the way fits into buildmagic ;) --jason On Thu, 3 Oct 2002, James Higginbotham wrote: Jason, I had submitted an example directly to David sometime last week, but I'll share with the world now so that the entire Jboss team can benefit. Its not a Java project per se, as it really only uses a sitemap.xml and an XSL to produce another ant script for running XSL transformations on a web site I manage. But, you are welcome to use it as a starting point. I was hoping to convert a project that I am managing from using redundant task bodies to use something like (half-baked mind you): module name=Foo depends module name=Bar/ /depends libs lib ref=my.class.path.ref /libs ear/ war/ java/ xdoclet/ /module But for now, take a look at the following project for an example of using XSL + XML to produce dynamic Ant scripts. Not sure if it will help, but see if it will get you started. I can answer any questions you have about how it works, as I am fluent in XSL. cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin The interesting files are the src/web/xml/sitemap.xml , src/web/xml/sitemap-build.xsl, and if you run the ant script with an XSL engine in your $ANT_HOME/lib, it will produce a file called autogen-build.xml in src/web/xml HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 9:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirl ist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL
Re: [JBoss-dev] Build System... any ideas
Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet I made the output (jar) tasks run in parallel. I can not make the xdoclet tasks run in parallel, looks like XDoclet is not thread-safe :( I really wish XDoclet was faster and less verbose... it complains too much. tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. I am still thinking about how to continue with this. This might wait until I figure out a better include/xslt/scripting system, as changing build.xml files (to keep things consistent) is a huge pain in the ass. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Jason, The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Not sure by what you mean re: maitennance. If you're talking about reading the code, I think that it's going to be easier for Joe JBoss Developer to read well-written Java code than it would be to read JavaScript, ANT XML, or some other language. We already know Java :) Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. Again, I'm new, so I don't know what an included module is... The build process in the compiled-build-system approach can be quite simple. The way the it works, is that you bootstrap your build system. Write a snippet of ANT XML that builds the build system ( 50 lines). Then run the build system like any other Java application. The thing that makes ant useful is the platform independence and API, and not the XML format, IMO. What do you gain with a scripting language over ANT XML? Expressiveness - control structures, other APIs, flexibility... You get all of this plus instant familiarity and a minimal learning curve when you use Java. What do you gain with a scripting language over Java? Doesn't require compilation. I know that it is conventional wisdom that build systems should be scripts, but I don't see the need in this case. Again, I know that this is an unusual method, and as such don't expect you to adopt it. I am, however, happy to discuss it further if you are interested. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think
RE: [JBoss-dev] Build System... any ideas
David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think
RE: [JBoss-dev] Build System... any ideas
module name=Foo depends module name=Bar/ /depends libs lib ref=my.class.path.ref /libs ear/ war/ java/ xdoclet/ /module YES! at least I can read that, (I really can't read 90% of the buildmagic files, jason do you have the cojones to get rid of your own work for something better? I did for JBoss 1.0 when Rickard proposed Dynamic Proxies) One thing that is nice in BM is the multiple ant files where each project defines the build files. But frankly I would rather have repetition of variables than unreadable stuff. In what you propose, we need sar ??? or is it just a jar file? Also I would also make the lib optional since we use UCLs in JBoss and can dynamically add a library you drop, so we would define the default and let the files be put in a central lib location of JBoss. I have been fighting with the declaration of all the files for tapestry... pain in my ass. We need tighter configuration with Open Source players. The idea here is clearly create a ANT ON JBOSS project. Just like we enhanced Tomcat with hotdeploy and it becomes a must to use Tomcat on JBoss instead of straight Tomcat, we must simplify the ANT stuff by using it on JBoss. Frankly JUST THE CLASSPATH NIGHTMARE GONE would be a HUGE/HUGE/HUGE step. So before we go and complicate things (jason) let's just do this simple one with the STRAIGHT ANT TAGS and it will be a HUGE HUGE HUGE step. Building is still a BIG pain in the ass and we need to automate some of that. BUILD ON JBOSS or ANT ON JBOSS can simplify things, integrate nicely with the XDoclet tags we are bringing back under JBoss and assure you that building on JBoss will be simple. Right now I am fighting with Tapestry for no good reason, except classpath mess, build files with BM that make no sense and bla bla bla. PLEASE LET MAKE OUR BUILD ENVIRONMENT THE BEST IN THE OPEN SOURCE WORLD, it doesn't take much, just simplifying some of the ant stuff and extending. Keep it really simple. It will be key to the fight for dominance, so let's get our ducks in a row. Anyone from ANT with a JBoss RW? Who can we bring under JBoss Group professional umbrella. We are doing business in helping people set their build environments today so I know there is some money to be made there. Step up! marc f But for now, take a look at the following project for an example of using XSL + XML to produce dynamic Ant scripts. Not sure if it will help, but see if it will get you started. I can answer any questions you have about how it works, as I am fluent in XSL. cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin The interesting files are the src/web/xml/sitemap.xml , src/web/xml/sitemap-build.xsl, and if you run the ant script with an XSL engine in your $ANT_HOME/lib, it will produce a file called autogen-build.xml in src/web/xml HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 9:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt
RE: [JBoss-dev] Build System... any ideas
I am thinking about how to do this. --jason On Fri, 20 Sep 2002, Scott M Stark wrote: Less mysteriousness, as in: !-- | Initialize the build system. Must depend on '_buildmagic:init'. | Other targets should depend on 'init' or things will mysteriously fail. -- target name=init unless=init.disable depends=_buildmagic:init /target I would like standard Ant + JBoss custom Ant tasks + scripting? all manifest in the build.xml files rather than hidden in corners of the build system. Absolutely, Scott is right RE: un-necessary complicated stuff that makes NO sense to a reader and serves an obscure goal. Jason, PLEASE START FROM SCRATCH. Ant + JBoss/ant/XDoclet tasks + JBoss classloaders (for lib visibility). I am not sure the last bit works as I can't remember how we pass the classpath to the javac runtime. I remember Jules gosnell had a trick to make it work so it is feasable. PLEASE LET'S RETURN TO A STRAIGHT ANT SYSTEM, LET'S DROP THE CURRENT SYSTEM marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Jason,
please pay close attention here.
I want you to justify in less than 10 seconds, what BM brings above and
beyond straight ANT. Give me examples in JBoss. I am sorry to put you
through this again. You know how I feel about complex stuff vs simple
stuff.
Also we have a contracting agreement in place with FGM and I would like
to take it to you guys to see if we can fund some of that cleaning up
of the build system. We need ANT ON JBOSS (ANT+) on JBoss and if you
funded some of that we would really allocate the resources to do it once
and for all. If you are interested I can talk to Xandy.
marc f
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Jason Dillon
Sent: Thursday, October 03, 2002 10:33 PM
To: Scott Sayles
Cc: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Build System... any ideas
Sorry for the delay...
Probably the biggest annoyance I have with using a
sub-module is that
the ${project.root} property within the sub-module ends up
including
the module above it instead of being the actual project root, so I
have to define my own local ${project.root.local} property in each
sub-module. To illustrate:
from a first level module:
${project.root}=/home/ssayles/src/myProject
from within a sub-module:
${project.root}=/home/ssayles/src/myProject/myModule
Is it possible to get this value to remain the real project root?
Perhaps I'm missing something?
Sub-modules are not supported at the moment. Currently all
modules must be
direct peers. I might find a way around this in the future.
Also, one of my thoughts is that we should raise developer
awareness
about the associated tests for a module. In other words, if they
change something in the code which breaks the tests for
that module,
this should be readily apparent. Of course, this will
happen when you
This is planned.
2. Force the integration of the module build with the associated
testsuite. In other words, have build targets within the
module call
correlating targets in the testsuite sub-module. This does
not seem
to fit within the buildmagic way of doing things (to me),
but it could
work.
Perhaps... will have to see. Would probably be better to leave them
seperate but require developers to run the modele tests. I
know what you
mean though... problems is that by doing so, making small changes and
recompiling would take too long.
Or I could short-circuit with unless properties.
Anyways... we'll see.
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task
RE: [JBoss-dev] Build System... any ideas
Why is it that evry time I make the build system easier/faster/beter that you start bitching at me with non-sensical dribble? Absolutely, Scott is right RE: un-necessary complicated stuff that makes NO sense to a reader and serves an obscure goal. I am convined that anything that I do you will think is too complicated... perhaps it is too much for you to handle? =P Jason, PLEASE START FROM SCRATCH. Ant + JBoss/ant/XDoclet tasks + JBoss classloaders (for lib visibility). WTF does this mean? I do not get the JBoss/Ant/XDoclet mess you speak about. If you can explain it to me, perhaps I will agree with you. I am not sure the last bit works as I can't remember how we pass the classpath to the javac runtime. I remember Jules gosnell had a trick to make it work so it is feasable. What? Please dude... WTF are you trying todo? The the classpath is taken from the javac.classpath path. If you want to add to it localy youset the local.classpath property, if you need to add libraries you add that to the libraries.classpath path. Fuck, if you do not remember something why the fuck don't you just ask. PLEASE LET'S RETURN TO A STRAIGHT ANT SYSTEM, LET'S DROP THE CURRENT SYSTEM Whatever... you are fucking insane! Why don't you check out the 2.4 branch and try do work on that for a few weeks! Don't waste my time with this dribble. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use
Re: [JBoss-dev] Build System... any ideas
Probably not:-) My idea involved a complete rewrite of ant as a bunch of mbeans, using as much jmx functionality as possible. This was based on the observation that the ant team seems to struggle a lot with classloading and questions of exactly how detyped their interfaces should be, plus dynamic extensions. Since these are what jmx is so good at, I thought building ant on jmx made a lot of sense. I think perhaps what marc is talking about is to run ant within jboss as an mbean. Back in February I spent a week or so trying to make this work (so we could have an xdoclet deployer, drop your source code in and it gets xdoclet-ized, compiled, and deployed) but I could not work around the ant classloaders to make anything work. (as I recall, really basic ant scripts worked but xdoclet did not at all). As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. david jencks On 2002.10.04 19:01:58 -0400 Jason Dillon wrote: Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom
RE: [JBoss-dev] Build System... any ideas
Can you explain the Ant MBean thing to me please. Here's the way I see it. ANT features: core system composed of engine + modules engine loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every Task in ANT is invoked via Task.execute() XML definition allows flexible definition of Tasks (ANT XML) JMX features: core system composed of server + modules server loads modules at runtime mechanism for wrapping a POJO in a standard / generic API Mix and match of modules (via generic API) to create desired functionality Every MBean in JMX is invoked via MBean.invoke() XML definition allows flexible definition of MBeans (XMBean XML) So much overlap. For many of these things, JMX simply does the job better. Ever try to add a plugins feature to an application, so that your clients can add on their own extensions? After I found out about JMX, it was like a light went on -- this is the way to do it... What we're all trying to do -- build robust applications out of building blocks, self-consistent units. What ant has going for it is the functionality. All the cross-platform wrinkles worked out -- the javac task just works. What JMX has going for it is the architecture -- powerful, clear, classloading figured out, dependable, flexible. If we can put these together, we'll have many benefits for both projects. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Friday, October 04, 2002 7:02 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm
RE: [JBoss-dev] Build System... any ideas
David, As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. Yeah, there's a lot of paranoid classes in there. If we show them that something useful can be done by opening up more of the ant core to the public interface, however, I think they'll fold it into the code base. It's not like it needs that much tweaking. I think that they are mainly concerned about not falling into the same pitfalls as make did. As long as it's clear that we're not trying to change ANT into something baroque and complex and contorted, I think they'll be alright. Plus, opening up the core API is good for IDE integration -- one of their goals. Of course, this assumes that politics is not an issue... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, October 04, 2002 8:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Probably not:-) My idea involved a complete rewrite of ant as a bunch of mbeans, using as much jmx functionality as possible. This was based on the observation that the ant team seems to struggle a lot with classloading and questions of exactly how detyped their interfaces should be, plus dynamic extensions. Since these are what jmx is so good at, I thought building ant on jmx made a lot of sense. I think perhaps what marc is talking about is to run ant within jboss as an mbean. Back in February I spent a week or so trying to make this work (so we could have an xdoclet deployer, drop your source code in and it gets xdoclet-ized, compiled, and deployed) but I could not work around the ant classloaders to make anything work. (as I recall, really basic ant scripts worked but xdoclet did not at all). As far as I know ant is still remarkably unfriendly to attempts to run it inside anything else, most of the methods needed are private or package access. david jencks On 2002.10.04 19:01:58 -0400 Jason Dillon wrote: Can you explain the Ant MBean thing to me please. --jason On Fri, 4 Oct 2002, David Jencks wrote: On 2002.10.04 09:39:07 -0400 Matt Munz wrote: David, I forget -- were you the one that started that thread re: ANT JMX on the ant-dev mailing list? I don't remember, but I've suggested ant should be a set of mbeans at least twice on the ant-dev list. david It makes so much sense it's scary :) I think refactoring ANT and JMX/JBoss is a great idea, from a technical (apolitical) standpoint. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find
RE: [JBoss-dev] Build System... any ideas
The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a lot less trouble. We would still need Java tests to run stuff that is type dependant, but the two could live together happy. The build system overhaul is a dependency of this I believe. I have been planning on doing all of the above... just I haven't had the time to make any progress. Also I really want to finish the basic command line console framework. Fuck, I need my boss to stop making me work on their lame ass projects. Who cares about that shit really... bah! --jason -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need
RE: [JBoss-dev] Build System... any ideas
As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code
Re: [JBoss-dev] Build System... any ideas
FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test
Re: [JBoss-dev] Build System... any ideas
This is done, though only Ant 1.5 aware tools will function at the moment. If there are other version that need to be compatible (if they can be) let me know. --jason On Thu, 19 Sep 2002, Scott M Stark wrote: Anymove that restores that ability to run our build in Ant aware tools is a good thing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:29 PM Subject: RE: [JBoss-dev] Build System... any ideas I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I can not find the include task in the 1.5 branch of Ant. I see some proposal/embed stuff in HEAD... but I can not get it to compile. --jason On Thu, 19 Sep 2002, David Jencks wrote: On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I have some ideas on using xslt, but I am not sure what the performance impact would be. I would need your help to write the stylesheets though... --jason On Thu, 19 Sep 2002, David Jencks wrote: There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net
Re: [JBoss-dev] Build System... any ideas
Right, we can publish all of the build documentation. --jason On Fri, 20 Sep 2002, David Jencks wrote: I agree. Having them posted might encourage people to make them more accurate and comprehensive. The xdoclet-generated todo list would be good also. This is now generated by the all build. Along with the javadocs I'd like to suggest we work a little more on the jmx-api docs I started on that basically provide a user manual for mbeans from xdoclet markup in the source. The info provided is basically the same you get on jmx-console with an xmbean (currently XidFactory and TransactionManagerService), but I think it's good to have it as static html also. I sort of enabled this everywhere by including the targets in documentation.ent, however due to parsing problems with xdoclet on excaped unicode characters it is currently disabled everywhere. I hope to have a solution soon. So, this isn't so much a build system request as a suggestion that we add additional documentation to all our mbeans (and convert them all to xmbeans). xdocletgui makes this pretty simple, it shows you what tags are available and lets you add them and fill in the values. david jencks On 2002.09.20 11:59:09 -0400 Dain Sundstrom wrote: I think it would be cool (which means it is not a formal request) to be able to have some tasks that can build the javadocs and push them to our webserver (of course you would have to authenticate by hand). It would be nice if this were simple, so we can have (trusted) others post results to our site. Actually, it would be better to have the automatic build scripts that Chris runs to be integrated into the build system with server push. What I mean is every night we pull down the new code, build, run the tests, generate the java docs, and post the source, binary (if built), the test results, and the java docs to the JBoss website. This would be similar to the Jakarta nightly builds. No matter what we do I think we should have the JBoss javadocs posted on our site or available for download. Maybe it is already there and I can't find it. What do you think? -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
Sounds like a good idea. I will set this up when I get to fixing the snapshots. --jason On Fri, 20 Sep 2002, Dain Sundstrom wrote: I think it would be cool (which means it is not a formal request) to be able to have some tasks that can build the javadocs and push them to our webserver (of course you would have to authenticate by hand). It would be nice if this were simple, so we can have (trusted) others post results to our site. Actually, it would be better to have the automatic build scripts that Chris runs to be integrated into the build system with server push. What I mean is every night we pull down the new code, build, run the tests, generate the java docs, and post the source, binary (if built), the test results, and the java docs to the JBoss website. This would be similar to the Jakarta nightly builds. No matter what we do I think we should have the JBoss javadocs posted on our site or available for download. Maybe it is already there and I can't find it. What do you think? -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I agree... but the trick is to accomplish this and still keep the build files simple, small. I am thinking about how to do this. --jason On Fri, 20 Sep 2002, Scott M Stark wrote: Less mysteriousness, as in: !-- | Initialize the build system. Must depend on '_buildmagic:init'. | Other targets should depend on 'init' or things will mysteriously fail. -- target name=init unless=init.disable depends=_buildmagic:init /target I would like standard Ant + JBoss custom Ant tasks + scripting? all manifest in the build.xml files rather than hidden in corners of the build system. Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL
RE: [JBoss-dev] Build System... any ideas
Sorry for the delay...
Probably the biggest annoyance I have with using a sub-module is that
the ${project.root} property within the sub-module ends up including the
module above it instead of being the actual project root, so I have to
define my own local ${project.root.local} property in each sub-module.
To illustrate:
from a first level module:
${project.root}=/home/ssayles/src/myProject
from within a sub-module:
${project.root}=/home/ssayles/src/myProject/myModule
Is it possible to get this value to remain the real project root?
Perhaps I'm missing something?
Sub-modules are not supported at the moment. Currently all modules must be
direct peers. I might find a way around this in the future.
Also, one of my thoughts is that we should raise developer awareness
about the associated tests for a module. In other words, if they change
something in the code which breaks the tests for that module, this
should be readily apparent. Of course, this will happen when you
This is planned.
2. Force the integration of the module build with the associated
testsuite. In other words, have build targets within the module call
correlating targets in the testsuite sub-module. This does not seem to
fit within the buildmagic way of doing things (to me), but it could
work.
Perhaps... will have to see. Would probably be better to leave them
seperate but require developers to run the modele tests. I know what you
mean though... problems is that by doing so, making small changes and
recompiling would take too long.
Or I could short-circuit with unless properties.
Anyways... we'll see.
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working
RE: [JBoss-dev] Build System... any ideas
Jason, I had submitted an example directly to David sometime last week, but I'll share with the world now so that the entire Jboss team can benefit. Its not a Java project per se, as it really only uses a sitemap.xml and an XSL to produce another ant script for running XSL transformations on a web site I manage. But, you are welcome to use it as a starting point. I was hoping to convert a project that I am managing from using redundant task bodies to use something like (half-baked mind you): module name=Foo depends module name=Bar/ /depends libs lib ref=my.class.path.ref /libs ear/ war/ java/ xdoclet/ /module But for now, take a look at the following project for an example of using XSL + XML to produce dynamic Ant scripts. Not sure if it will help, but see if it will get you started. I can answer any questions you have about how it works, as I am fluent in XSL. cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin The interesting files are the src/web/xml/sitemap.xml , src/web/xml/sitemap-build.xsl, and if you run the ant script with an XSL engine in your $ANT_HOME/lib, it will produce a file called autogen-build.xml in src/web/xml HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 9:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirl ist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional
RE: [JBoss-dev] Build System... any ideas
Sorry to post to this list but I'm currently dealing with this issue in
my own project and thought it would be appropriate to comment. Also,
I'm not sure where to post any buildmagic related questions or if there
is such a place to do so.
We've recently switched to buildmagic. I've more recently been setting
up testsuites just as you are suggesting here (where specific modules
have their own testsuite sub-module). We are currently intending to
implement a master testsuite module to run the other testsuites and to
perhaps contain cross module tests. So far, things are going ok but
there are some issues I'm trying to figure out.
Probably the biggest annoyance I have with using a sub-module is that
the ${project.root} property within the sub-module ends up including the
module above it instead of being the actual project root, so I have to
define my own local ${project.root.local} property in each sub-module.
To illustrate:
from a first level module:
${project.root}=/home/ssayles/src/myProject
from within a sub-module:
${project.root}=/home/ssayles/src/myProject/myModule
Is it possible to get this value to remain the real project root?
Perhaps I'm missing something?
Also, one of my thoughts is that we should raise developer awareness
about the associated tests for a module. In other words, if they change
something in the code which breaks the tests for that module, this
should be readily apparent. Of course, this will happen when you
execute the main build if you have your module/testsuite listsed as a
module. But I find that I will build often from within a specific
module that I'm working on and don't want to execute the main build
because it takes too long. I'm pretty new to buildmagic, so please
correct me if I'm mistaken in my approach. Based on this, I see two
probable scenarios for structuring the build for the sub-module
testsuites:
1. Add them as modules in the main build and continue to use the main
build.
e.g. modules=moduleFoo/testsuite
This seems to fit appropriately within buildmagic
2. Force the integration of the module build with the associated
testsuite. In other words, have build targets within the module call
correlating targets in the testsuite sub-module. This does not seem to
fit within the buildmagic way of doing things (to me), but it could
work.
I like option 2 because when I run moduleFoo/build.sh, I know
immediately if I've broken a test compilation. But I'm not sure if we
should set things up like this. Any suggestions?
Thanks.
Scott
On Thu, 2002-09-19 at 20:48, Jason Dillon wrote:
So are you suggesting that there be, more or less, a build file per
testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then
the
testsuite/build.xml calls each of them?
No, I am suggesting there be a testsuite in each module.
build/build.xml would be configured to recurse into them collect the
results for a final report. Or you could just run the module testsuite
for the bits you are working on.
Or if you are just interested in the integration tests, you can run
jboss/testsuite. Or if you just care about how jboss/cluster works, you
might run the cluster and testsuite module's tests target.
I think that would accomplish essentially the same thing I was
suggesting
with the generic targets for run xdoclet in one directory and build
jars from one directory suggestion.
Hrm, you gonna have to explain this again... I don't understand what ya
mean here. Sorry =]
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I think it would be cool (which means it is not a formal request) to be able to have some tasks that can build the javadocs and push them to our webserver (of course you would have to authenticate by hand). It would be nice if this were simple, so we can have (trusted) others post results to our site. Actually, it would be better to have the automatic build scripts that Chris runs to be integrated into the build system with server push. What I mean is every night we pull down the new code, build, run the tests, generate the java docs, and post the source, binary (if built), the test results, and the java docs to the JBoss website. This would be similar to the Jakarta nightly builds. No matter what we do I think we should have the JBoss javadocs posted on our site or available for download. Maybe it is already there and I can't find it. What do you think? -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I agree. Having them posted might encourage people to make them more accurate and comprehensive. The xdoclet-generated todo list would be good also. This is now generated by the all build. Along with the javadocs I'd like to suggest we work a little more on the jmx-api docs I started on that basically provide a user manual for mbeans from xdoclet markup in the source. The info provided is basically the same you get on jmx-console with an xmbean (currently XidFactory and TransactionManagerService), but I think it's good to have it as static html also. I sort of enabled this everywhere by including the targets in documentation.ent, however due to parsing problems with xdoclet on excaped unicode characters it is currently disabled everywhere. I hope to have a solution soon. So, this isn't so much a build system request as a suggestion that we add additional documentation to all our mbeans (and convert them all to xmbeans). xdocletgui makes this pretty simple, it shows you what tags are available and lets you add them and fill in the values. david jencks On 2002.09.20 11:59:09 -0400 Dain Sundstrom wrote: I think it would be cool (which means it is not a formal request) to be able to have some tasks that can build the javadocs and push them to our webserver (of course you would have to authenticate by hand). It would be nice if this were simple, so we can have (trusted) others post results to our site. Actually, it would be better to have the automatic build scripts that Chris runs to be integrated into the build system with server push. What I mean is every night we pull down the new code, build, run the tests, generate the java docs, and post the source, binary (if built), the test results, and the java docs to the JBoss website. This would be similar to the Jakarta nightly builds. No matter what we do I think we should have the JBoss javadocs posted on our site or available for download. Maybe it is already there and I can't find it. What do you think? -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
Less mysteriousness, as in: !-- | Initialize the build system. Must depend on '_buildmagic:init'. | Other targets should depend on 'init' or things will mysteriously fail. -- target name=init unless=init.disable depends=_buildmagic:init /target I would like standard Ant + JBoss custom Ant tasks + scripting? all manifest in the build.xml files rather than hidden in corners of the build system. Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
RE: [JBoss-dev] Build System... any ideas
So all of the examples you list which depend on other modules to function are integration tests. You could imagine that for Naming you might have a simple test which only tests the basic protocol handshaking, versioning or whatever. For transactions you might have a simple test to make sure that the UserTransaction class functions as expected. I can't think of an example of security... 'cause don't really know anything about it. My point is that most of our tests cover a vary large area. A single test might hit deployment, ejb container startup, jndi proxy factory lookup, factory creation, proxy invocation. I agree that these tests are very important and needed, but what about testing each of these steps in isolation? This would help detect finer grained problems faster and provide better coverage overall. That is one point, the second is where those tests should go. I believe they should be closer to the code which they are testing, rather than put into a monolithic testsuite module. BUT this is only for tests as I mention above, which only test the components. One reason for this is for modules which span projects, the core testsuite for the code will move with it, rather than have to pick apart jboss/testsuite for the correct bits. This is an organizational concept, where module test code stays with the module, where tests which cover more than one module live in the testsuite module. Take the jboss/common module. This module depends on nothing. There are many classes here which could benefit from simple tests to validate the functionality of the code which resides here. These classes are also used through-out the entire server, so they will also be tested by other tests as well. That does not mean that they are better suited to live in the testsuite module. As it stands right now, the testsuite module is too big and too complex. By moving the non-dependent tests closer to the code they are testing we simplify and organize. I believe that a simple and organized testing system will help encourage developers (new and old) to write more tests. It seems clear to me... --jason Security is one example. There is secured sockets to the various interceptors, web container, JMS, etc. which are basic transport tests that affects several models. Then there is declarative security that could be in one component layer, or involve the propagation across layers. Naming is another. How JNDI interacts with the components environments is not an isolated functionality. Transactions are another. JMX is another. Sure Juha has his own little view of the JMX spec, but given that it is the bus on which everything lives there are many component interactions that have to be tested across modules. This is only going to be more so as security, transactions, naming ENCs, class loading, etc. are brought to MBeans. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 5:23 PM Subject: RE: [JBoss-dev] Build System... any ideas Okay, no worries. What don't you get? Which tests specifically are you thinking of when you say then involve several functional modules? Just one for an example, so I can see where you are coming from is fine. Basically most of jboss/testsuite will remain the same, as many of those tests require a running JBoss instance and use many components from many modules to function. But there are a subset, like the proxy compiler tests, or the JBossMQ selector parser tests, which do not. So far most of our tests have been functional tests of a component from start to end. I am suggesting that we could make more tests which test individual parts (with out running a JBoss instance)... perhaps using mock objects for bits that we need to run them. This will give us more coverage and will allow the functional tests to simply test the integration not the functionality of the individual components. By putting these independent tests in the corresponding module, we make the testsuite more maintainable by preventing jboss/testsuite from becoming insanely huge. Does that make sense or shall I explain more. Perhaps I am not wording things correctly, or I am taking some bit of knowledge for granted? --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing
RE: [JBoss-dev] Build System... any ideas
Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any
Re: [JBoss-dev] Build System... any ideas
Its not clear to me. What is the module closest to testing the progation of the security context from a war to an EJB over SSL with authentication done using client certificates? I don't buy the organizational concept as most of the work is setting up the components, not the basic functionality testing. If there are truly module isolated functional tests, put these in the module, but cross module testing belongs in a teststuite module with the infrastructure setup to simplify creating, building and running the tests. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 12:30 PM Subject: RE: [JBoss-dev] Build System... any ideas So all of the examples you list which depend on other modules to function are integration tests. You could imagine that for Naming you might have a simple test which only tests the basic protocol handshaking, versioning or whatever. For transactions you might have a simple test to make sure that the UserTransaction class functions as expected. I can't think of an example of security... 'cause don't really know anything about it. My point is that most of our tests cover a vary large area. A single test might hit deployment, ejb container startup, jndi proxy factory lookup, factory creation, proxy invocation. I agree that these tests are very important and needed, but what about testing each of these steps in isolation? This would help detect finer grained problems faster and provide better coverage overall. That is one point, the second is where those tests should go. I believe they should be closer to the code which they are testing, rather than put into a monolithic testsuite module. BUT this is only for tests as I mention above, which only test the components. One reason for this is for modules which span projects, the core testsuite for the code will move with it, rather than have to pick apart jboss/testsuite for the correct bits. This is an organizational concept, where module test code stays with the module, where tests which cover more than one module live in the testsuite module. Take the jboss/common module. This module depends on nothing. There are many classes here which could benefit from simple tests to validate the functionality of the code which resides here. These classes are also used through-out the entire server, so they will also be tested by other tests as well. That does not mean that they are better suited to live in the testsuite module. As it stands right now, the testsuite module is too big and too complex. By moving the non-dependent tests closer to the code they are testing we simplify and organize. I believe that a simple and organized testing system will help encourage developers (new and old) to write more tests. It seems clear to me... --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
This is exactly my point. This is the same thing that I am saying. most of the work is setting up the components, not the basic functionality testing. If there are truly module isolated functional tests, put these in the module, but cross module testing belongs in a teststuite module with the infrastructure setup to simplify creating, building and running the tests. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about
RE: [JBoss-dev] Build System... any ideas
I can't release the scripts from the company I work at, but I can point you to a project I work on that is simply a website put together using XSL + XML. It uses the same principles in its design and should give you an overview. Using anon CVS to fetch: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin Again, no J2EE but the concepts are there. Basically, it uses a sitemap in XML as its data source. So, I use XSL to generate a script to generate HTML using XSL ;) Just apply this concept to generating Ant scripts of any sort, including module building and deployment, classpaths for modules based on jar dependencies, etc. James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 3:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlis t Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would
Re: [JBoss-dev] Build System... any ideas
Then don't use 10 paragraphs to say it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 20, 2002 1:20 PM Subject: RE: [JBoss-dev] Build System... any ideas This is exactly my point. This is the same thing that I am saying. most of the work is setting up the components, not the basic functionality testing. If there are truly module isolated functional tests, put these in the module, but cross module testing belongs in a teststuite module with the infrastructure setup to simplify creating, building and running the tests. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a lot less trouble. We would still need Java tests to run stuff that is type dependant, but the two could live together happy. The build system overhaul is a dependency of this I believe. I have been planning on doing all of the above... just I haven't had the time to make any progress. Also I really want to finish the basic command line console framework. Fuck, I need my boss to stop making me work on their lame ass projects. Who cares about that shit really... bah! --jason -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development
Re: [JBoss-dev] Build System... any ideas
Anymove that restores that ability to run our build in Ant aware tools is a good thing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:29 PM Subject: RE: [JBoss-dev] Build System... any ideas I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I don't really see how module local tests are any improvement over the test and one-test targets in the existing testsuite module. In some ways it is a problem because now you have additional dependencies to build and run the tests in the module. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:29 PM Subject: RE: [JBoss-dev] Build System... any ideas David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a lot less trouble. We would still need Java tests to run stuff that is type dependant, but the two could live together happy. The build system overhaul is a dependency of this I believe. I have been planning on doing all of the above... just I haven't had the time to make any progress. Also I really want to finish the basic command line console framework. Fuck, I need my boss to stop making me work on their lame ass projects. Who cares about that shit really... bah! --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
They are an improvement, though the extent of that will vary from user to user. For example, it is much easier to say: ./cluster/build.sh tests Than to figure out the test class names and then look up the proper target to call and the properties to set (in case you forgot, like I always do). It basically makes it easier to run smaller chunks of the tests. If you still just want to run one single test, then there is no real advantage. It is possible that there could be new dependency related issues, but I hope to resolve the with new build system components which can figure these out automatically... well with minimal configuration is more likely. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Thursday, September 19, 2002 2:36 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas I don't really see how module local tests are any improvement over the test and one-test targets in the existing testsuite module. In some ways it is a problem because now you have additional dependencies to build and run the tests in the module. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:29 PM Subject: RE: [JBoss-dev] Build System... any ideas David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a lot less trouble. We would still need Java tests to run stuff that is type dependant, but the two could live together happy. The build system overhaul is a dependency of this I believe. I have been planning on doing all of the above... just I haven't had the time to make any progress. Also I really want to finish the basic command line console framework. Fuck, I need my boss to stop making me work on their lame ass projects. Who cares about that shit really... bah! --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
I think that we can probably do this... such that any Ant (greater than the supported version) would work... but it will require some effort to figure out a way to allow scripts to share data. I think that using the script task could possibly help resolve many of the include issues. I am confident that we can transform the build system in subtle ways (ie. no major structure changes or anything like that) to get it working in most if not all Ant aware IDE's. I do however believe that we should move carefully on this, so we don't have to mess with this again in 6 months. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Thursday, September 19, 2002 2:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas Anymove that restores that ability to run our build in Ant aware tools is a good thing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:29 PM Subject: RE: [JBoss-dev] Build System... any ideas I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
They'd probably solve the problem of 7 minutes to build to run a single
test that I experience.
Moving stuff to module specific test dirs would be a lot of work. I wonder
if instead we could make dir-specific generic build targets -- something
like in ${test.module} run xdoclet, compile all classes, then run jar for
${test.module}, then run tests in that module also. Sort of like test
but limiting the xdoclet and jar tasks also.
The build file is getting so large this might help make it more
comprehensible also.
david jencks
On 2002.09.19 17:36:29 -0400 Scott M Stark wrote:
I don't really see how module local tests are any improvement over the
test and
one-test targets in the existing testsuite module. In some ways it is a
problem
because now you have additional dependencies to build and run the tests
in
the module.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 10:29 PM
Subject: RE: [JBoss-dev] Build System... any ideas
David and I talked about this on the way back from Tahoe. I would like
to revisit the entire TestSuite, putting a testsuite in each module,
which would perform Unit tests for components and parts of components
for that module alone. Then the jboss/testsuite would be an
integration
testsuite.
This way, if you are working on bits from the cluster module, you can
write simple tests to validate your component and run the tests
quickly.
Then when you are satisfied, you can write an integration test, which
would actual test a real component inside of a JBoss instance.
This will get us more coverage, but will also encourage developers to
make smaller, simpler tests for stuff and make it more likely they will
run them, as it won't take forever.
Also, on the subject of build systems and testsuites, I have been
toying
with the idea of allow Java and Jython tests to be run together. Using
Jython it will be faster to throw together small and functional tests
with much less code and a lot less trouble. We would still need Java
tests to run stuff that is type dependant, but the two could live
together happy.
The build system overhaul is a dependency of this I believe.
I have been planning on doing all of the above... just I haven't had
the
time to make any progress. Also I really want to finish the basic
command line console framework.
Fuck, I need my boss to stop making me work on their lame ass projects.
Who cares about that shit really... bah!
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
jbossmx already has its own module specific test suite rather than
integrating with the jboss testsuite module so I would welcome the change
jason suggests where jboss testsuite integrates tests from individual modules if
they exist
-- Juha
On Thu, 19 Sep 2002, David Jencks wrote:
They'd probably solve the problem of 7 minutes to build to run a single
test that I experience.
Moving stuff to module specific test dirs would be a lot of work. I wonder
if instead we could make dir-specific generic build targets -- something
like in ${test.module} run xdoclet, compile all classes, then run jar for
${test.module}, then run tests in that module also. Sort of like test
but limiting the xdoclet and jar tasks also.
The build file is getting so large this might help make it more
comprehensible also.
david jencks
On 2002.09.19 17:36:29 -0400 Scott M Stark wrote:
I don't really see how module local tests are any improvement over the
test and
one-test targets in the existing testsuite module. In some ways it is a
problem
because now you have additional dependencies to build and run the tests
in
the module.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 10:29 PM
Subject: RE: [JBoss-dev] Build System... any ideas
David and I talked about this on the way back from Tahoe. I would like
to revisit the entire TestSuite, putting a testsuite in each module,
which would perform Unit tests for components and parts of components
for that module alone. Then the jboss/testsuite would be an
integration
testsuite.
This way, if you are working on bits from the cluster module, you can
write simple tests to validate your component and run the tests
quickly.
Then when you are satisfied, you can write an integration test, which
would actual test a real component inside of a JBoss instance.
This will get us more coverage, but will also encourage developers to
make smaller, simpler tests for stuff and make it more likely they will
run them, as it won't take forever.
Also, on the subject of build systems and testsuites, I have been
toying
with the idea of allow Java and Jython tests to be run together. Using
Jython it will be faster to throw together small and functional tests
with much less code and a lot less trouble. We would still need Java
tests to run stuff that is type dependant, but the two could live
together happy.
The build system overhaul is a dependency of this I believe.
I have been planning on doing all of the above... just I haven't had
the
time to make any progress. Also I really want to finish the basic
command line console framework.
Fuck, I need my boss to stop making me work on their lame ass projects.
Who cares about that shit really... bah!
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
I am convinced that is the way to go... it is really a matter of how and
when really.
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On Behalf Of Juha-P Lindfors
Sent: Thursday, September 19, 2002 3:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Build System... any ideas
jbossmx already has its own module specific test suite rather than
integrating with the jboss testsuite module so I would welcome the
change
jason suggests where jboss testsuite integrates tests from individual
modules if
they exist
-- Juha
On Thu, 19 Sep 2002, David Jencks wrote:
They'd probably solve the problem of 7 minutes to build to run a
single
test that I experience.
Moving stuff to module specific test dirs would be a lot of work. I
wonder
if instead we could make dir-specific generic build targets --
something
like in ${test.module} run xdoclet, compile all classes, then run
jar
for
${test.module}, then run tests in that module also. Sort of like
test
but limiting the xdoclet and jar tasks also.
The build file is getting so large this might help make it more
comprehensible also.
david jencks
On 2002.09.19 17:36:29 -0400 Scott M Stark wrote:
I don't really see how module local tests are any improvement over
the
test and
one-test targets in the existing testsuite module. In some ways it
is
a
problem
because now you have additional dependencies to build and run the
tests
in
the module.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 10:29 PM
Subject: RE: [JBoss-dev] Build System... any ideas
David and I talked about this on the way back from Tahoe. I
would
like
to revisit the entire TestSuite, putting a testsuite in each
module,
which would perform Unit tests for components and parts of
components
for that module alone. Then the jboss/testsuite would be an
integration
testsuite.
This way, if you are working on bits from the cluster module,
you
can
write simple tests to validate your component and run the tests
quickly.
Then when you are satisfied, you can write an integration test,
which
would actual test a real component inside of a JBoss instance.
This will get us more coverage, but will also encourage
developers
to
make smaller, simpler tests for stuff and make it more likely
they
will
run them, as it won't take forever.
Also, on the subject of build systems and testsuites, I have
been
toying
with the idea of allow Java and Jython tests to be run together.
Using
Jython it will be faster to throw together small and functional
tests
with much less code and a lot less trouble. We would still need
Java
tests to run stuff that is type dependant, but the two could
live
together happy.
The build system overhaul is a dependency of this I believe.
I have been planning on doing all of the above... just I haven't
had
the
time to make any progress. Also I really want to finish the
basic
command line console framework.
Fuck, I need my boss to stop making me work on their lame ass
projects.
Who cares about that shit really... bah!
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Juha Lindfors
Author of JMX: Managing J2EE with Java Management Extensions
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
On 2002.09.19 18:05:46 -0400 Scott M Stark wrote:
Add -Dnojars=true during the run of the single test and zero compilation
time is the result.
Umm, yes, I know about nojars, I wrote it.
It doesn't help much if you changed the test and need to recompile, the
situation I find time consuming.
Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the
tests
into the server.
Doesn't this require you to copy the appropriate test jar into the deploy
directory? Are there any deployments that take a significant amount of
time?
I routinely run single tests in 10 seconds with these
options. Refactoring
the entire testsuite for a simple usage problems is silly.
Having to spend 7 minutes to try a simple change to a test is a lot
sillier.
Breaking up the huge monolithic build file into seperates test files
would be a good thing.
This is what we had in 2.4 and it was nice when we had 200 tests. Now
as we
approach 1000 its time to revisit this as well.
Agreed, this is a better solution, but also more work. I think the
test/module in the modules is the way to go here.
david jencks
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 19, 2002 2:55 PM
Subject: Re: [JBoss-dev] Build System... any ideas
They'd probably solve the problem of 7 minutes to build to run a single
test that I experience.
Moving stuff to module specific test dirs would be a lot of work. I
wonder
if instead we could make dir-specific generic build targets --
something
like in ${test.module} run xdoclet, compile all classes, then run jar
for
${test.module}, then run tests in that module also. Sort of like
test
but limiting the xdoclet and jar tasks also.
The build file is getting so large this might help make it more
comprehensible also.
david jencks
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Okay, no worries. What don't you get? Which tests specifically are you thinking of when you say then involve several functional modules? Just one for an example, so I can see where you are coming from is fine. Basically most of jboss/testsuite will remain the same, as many of those tests require a running JBoss instance and use many components from many modules to function. But there are a subset, like the proxy compiler tests, or the JBossMQ selector parser tests, which do not. So far most of our tests have been functional tests of a component from start to end. I am suggesting that we could make more tests which test individual parts (with out running a JBoss instance)... perhaps using mock objects for bits that we need to run them. This will give us more coverage and will allow the functional tests to simply test the integration not the functionality of the individual components. By putting these independent tests in the corresponding module, we make the testsuite more maintainable by preventing jboss/testsuite from becoming insanely huge. Does that make sense or shall I explain more. Perhaps I am not wording things correctly, or I am taking some bit of knowledge for granted? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Thursday, September 19, 2002 4:32 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? No, I am suggesting there be a testsuite in each module. build/build.xml would be configured to recurse into them collect the results for a final report. Or you could just run the module testsuite for the bits you are working on. Or if you are just interested in the integration tests, you can run jboss/testsuite. Or if you just care about how jboss/cluster works, you might run the cluster and testsuite module's tests target. I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Hrm, you gonna have to explain this again... I don't understand what ya mean here. Sorry =] --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
Security is one example. There is secured sockets to the various interceptors, web container, JMS, etc. which are basic transport tests that affects several models. Then there is declarative security that could be in one component layer, or involve the propagation across layers. Naming is another. How JNDI interacts with the components environments is not an isolated functionality. Transactions are another. JMX is another. Sure Juha has his own little view of the JMX spec, but given that it is the bus on which everything lives there are many component interactions that have to be tested across modules. This is only going to be more so as security, transactions, naming ENCs, class loading, etc. are brought to MBeans. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 5:23 PM Subject: RE: [JBoss-dev] Build System... any ideas Okay, no worries. What don't you get? Which tests specifically are you thinking of when you say then involve several functional modules? Just one for an example, so I can see where you are coming from is fine. Basically most of jboss/testsuite will remain the same, as many of those tests require a running JBoss instance and use many components from many modules to function. But there are a subset, like the proxy compiler tests, or the JBossMQ selector parser tests, which do not. So far most of our tests have been functional tests of a component from start to end. I am suggesting that we could make more tests which test individual parts (with out running a JBoss instance)... perhaps using mock objects for bits that we need to run them. This will give us more coverage and will allow the functional tests to simply test the integration not the functionality of the individual components. By putting these independent tests in the corresponding module, we make the testsuite more maintainable by preventing jboss/testsuite from becoming insanely huge. Does that make sense or shall I explain more. Perhaps I am not wording things correctly, or I am taking some bit of knowledge for granted? --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
On 2002.09.19 20:48:17 -0400 Jason Dillon wrote: So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? No, I am suggesting there be a testsuite in each module. build/build.xml would be configured to recurse into them collect the results for a final report. Or you could just run the module testsuite for the bits you are working on. Right, I think Scott is suggesting keeping all or most of the tests in testsuite, but supplying a build.xml per directory for them. Or if you are just interested in the integration tests, you can run jboss/testsuite. Or if you just care about how jboss/cluster works, you might run the cluster and testsuite module's tests target. I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Hrm, you gonna have to explain this again... I don't understand what ya mean here. Sorry =] Well, we have a way of running one directory of tests -- -Dtest=jmx test. How about making xdoclet and jar targets per directory so when you run the above you run xdoclet-jmx-compile compile-java jar-jmx and the tests filtered for jmx? It's pretty similar to what Scott is proposing but keeps everything in one build file. david jencks --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build System... any ideas
There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome
Re: [JBoss-dev] Build System... any ideas
I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a lot less trouble. We would still need Java tests to run stuff that is type dependant, but the two could live together happy. The build system overhaul is a dependency of this I believe. I have been planning on doing all of the above... just I haven't had the time to make any progress. Also I really want to finish the basic command line console framework. Fuck, I need my boss to stop making me work on their lame ass projects. Who cares about that shit really... bah! --jason -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
