couple points: 1) if you use an interpreted language for builds, no compile is necessary. This is my main problem with gradle, if you have gradle builds that leverage code in your projects (e.g. a "gradle cleanDB" task that cleans your database using java code that is part of your project), you can't reference the java classes in your gradle build w/o first building your project. So you end up having to have a separate build that builds all your "dev" tasks like this. It's a bit awkward. A pure interpreted language (Ruby/Buildr) is nicer for builds.
2) For config files you could use something like Velocity or JSPs to mix in java code with your XML (or JSON/YAML) files. This way your code gets compiled at runtime. You are right - there is a balance in going against the grain. If you do something too "out there," there will be no one to ask when you get stuck. So do so with care. However given the nature of Java XML builds turning into multi-thousand lines of un-debuggable XML hell, I think going with the flow will lead to more pain than trail-blazing. There are some really bone-headed things that have gone on in the java world. My top three are Ant using XML files in place of a real scripting language, the misguided invention of Checked Exceptions, and the inherent instability introduced in the JVM by not allocating heap/permgen as needed (leading to the all to common OutOfMemoryException which leaves your app in a sort of running but mostly hosed state). On Mon, Mar 7, 2011 at 6:22 PM, Reinier Zwitserloot <[email protected]>wrote: > I learned many of these things on just java. For example, I've been looking > around casually for an all-in-code ant for years now (though as a purely > practical matter, for FOSS projects sticking to requiring only git+java+ant > to be installed, and that being enough to build just as well as the core > developers, is just worth more than having a somewhat easier job writing > build configs than pull gant into the mix. I am keeping an eye on gradle > though, might be worth it). > > Jetty's config is XML, but if you read between the lines of the > documentation, its pretty obvious its all just XML versions of java basics > (method calls, mostly), and, yup, you can do all that in plain old java too. > However, having to recompile some code just to change a port number or some > such can be a pain. I once built a really simplistic web framework on top of > jetty where ALL config (notably also the routing of URLs to 'servlets') was > done via annotations on the servlets themselves. This was particularly > elegant to me, and quite useful on that particular project, but made it hard > to integrate other projects provided for free by the java community. > > There's a point hidden in this walk down memory lane: Going against the > grain of a community (i.e. java's community) because you feel your way is > better, or, you've seen the light because another community (i.e. ruby's > community) likes to do things differently and you feel that way is > superior.... is not as productive as you might imagine. > > There are sometimes valid reasons for the seemingly inefficient way of > doing things, such as why jetty offers XML config and even assumes you'll be > using that in its out of the box install and its documentation (well, at > least before the docs were rewritten when jetty became org.eclipse.jetty - > haven't looked since): The compile step can be annoying. I guess in theory > this too can be nixed (by having jetty run javac on a .java 'config' file, > automatically picking up changes), but doing that runs afoul of established > tool chains, i.e. might cause problems when you're using an IDE or JRebel. > It's all connected; the inefficiency of writing config files in XML (which > admittedly team jetty could have eased a bit by using JSON or some such > instead) is necessary because java has a compilation step, but this > compilation step is related to java's excellent introspection tooling, > something ruby projects aren't nearly as good at. Which one is worth more? > That's hard to say, but its hard to have the one (in-code config) with the > other (good introspection). > > The second problem with going against the grain is, well, you're going > against the grain. Doing so causes friction. I usually end up loving my > technical improvements but in the end usually dump them anyway simply > because the elegance is not worth the headaches of being incompatible with > many other bits the community would have provided for you if only you hadn't > gone off and done a cool but non-standard trick. > > There are of course times going against the grain is a good thing. When > trailblazing a new kind of library, for example, or in cases where the > inefficiency burden of the established way of doing things grows so large > its worth changing. At these times you need someone capable of thinking of > other ways of solving the problem; learning about other communities is one > excellent way of getting there. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
