Friday, December 6, 2002

IBM buys Rational Lunchtime! IBM buys Rational. [Clemens Vasters: Enterprise Development & Alien Abductions] Wow. Hey I wonder if IBM's gonna open source Rose and add it into eclipse :-). 2:50:41 PM    comment []

.NET CLR Unsuitable for Interpretive Languages? .NET CLR Unsuitable for Interpretive Languages?. [::Manageability::] What with things like VB, Python and bytecode generation in Java being so popular this really suprises me. 11:07:40 AM    comment []

Java hygienic macros Java hygienic macros.  Ken Meltsner points out Java Syntactic Extensions, a macro system for Java. Great stuff, thanks for pointing it out!! Check out in the slides how the forEach statement (slide 30) is implemented in the system: the implementation fits in only one slide! The slides also show as example an accessible keyword (slide 39) which, when used to declare an instance variable, automatically generates setter and getter methods. One thing I liked about the system is that it's procedural, thus potentially easier to understand and master than the declarative syntax macros in Scheme. Even then however, it could still be a challenge to understand and master. Such a macro system would be the only thing needed in Java, everything else could be implemented using it. This is the case in most implementations of Scheme, which have a very small core and everything else is implemented as macros. [Ovidiu Predescu's Weblog] This looks very groovy stuff. Using a similar approach it'd be pretty trivial to add a using statement like the one in C# for handling the closing of resources like streams or database connections. using (InputStream in = new FileInputStream("foo.txt")) {   // do something } rather than the much more complex try / catch / finally clause, particularly when used with multiple resources. This also echos other bloggers recent posts, like Carlos, that we just need either hygienic macros or true support for blocks. 11:05:44 AM    comment []

Directory structures of builds Ideal directory structure. I'm trying to figure out an ideal directory structure for our future build system ... I'll put a project.xml in root and all app directory. My problem now is where to put common classes? [gru's logic] How about in src/java src/test For the code and unit tests? Its the pattern many Jakarta projects follow. You could use a seperate build for your webapp and EJBs if you like (i.e. seperate project.xml). 8:46:27 AM    comment []

why Maven? Maven?. Besides toying around with all the different AOP frameworks I still have a day job. Currently I'm converting the build process from pure Ant to Maven. My co-workers are still not convinced that it's worth it. I know there are loads of interesting features in it (I'm rereading Scott Ambler's Agile Modeling btw). But what are the truly compelling reasons? What does it buy me (besides tighter integration into an overall build/test/deployment iteration) and more importantly my colleagues? [gru's logic] For me the truly compelling reasons for using Maven are as follows... Once you describe what your dependencies are, Maven will pretty much automatically build and test your code, (properly instrumenting your jars' manifest of course) downloading any jars required to build your code from one or more remote repositories into a local repository. Maven will also build your entire website packed with oodles of useful reports, javadoc, cross referenced source code, unit test reports, style check reports, (optional clover test coverage reports).  Even better, by typing maven site:deploy It will build the site and deploy it on your website (internet, intranet etc) for you! maven dist Will create a binary distribution, including all the documentation, and deploy it for you too! e.g. checkout this example site. There's an example here of the different reports. Essentially the whole 'Project Documentation' section is generated by Maven for you - e.g. a full list of real dependencies used to build your system or the development team details and contacts. All of the above are pretty much my core reasons for using Maven. Here's a few other neat things I really like about Maven... The use of a local repository makes it easy to work on several related projects; I can try installing a personal version of a certain project via maven jar:install which will build a project and install its jar in the local repository so that another project can build against it. No more messing around manually copying jars around. Other handy things are the test:ui goal to run a Swing TestRunner or test:single and test:match for running individual unit tests or a pattern match of unit tests. Then there's the eclipse, idea and jbulder plugins to automatically create project files for your build, with all the correct class & source paths. Oh and the ability to create Ant or Gump builds. I won't even get into all the various plugins for working with XDoclet or WARs or Cactus or web servers or JavaCC etc. Is that enough to convince you yet? :-) 8:05:21 AM    comment []