#maven screams

That is, it screams by proxy. Through me. All it does by itself is barf verbose output.

Let’s try the absolute first example. After apparently trying to download the internet, it works. But hey, what’s this I notice in the output?

[INFO] [archetype:create]
[WARNING] This goal is deprecated. Please use mvn archetype:generate instead

That’s encouraging. Let’s try this when I create another project.

[…]
242: remote -> flexmojos-archetypes-modular-webapp (null)
243: remote -> nexus-plugin-archetype (null)
244: remote -> spring-osgi-bundle-archetype (Spring OSGi Maven2 Archetype)
245: remote -> spring-ws-archetype (Spring Web Services Maven2 Archetype.)
246: remote -> trails-archetype (null)
247: remote -> trails-secure-archetype (null)
248: remote -> tynamo-archetype (null)
249: remote -> circumflex-archetype (null)
Choose a number: 58:

Wait, WTF is this? “Pick a number, any number!” I didn’t come to play guessing games, I just want to generate a project in the approved way. Apparently even that essential, obvious step is too complex to “just work”. And heaven help me if I cd into one of the project directories I’ve created and try another project creation command:

[ERROR] BUILD ERROR
[INFO] ————————————————————————
[INFO] Error creating from archetype

Embedded error: Unable to add module to the current project as it is not of packaging type ‘pom’

Well, you know what they say. Clear as mud.

Yes, I’m being deliberately obtuse. I can figure out what’s going on here. But come on; this is ridiculous. Isn’t maven supposed to simplify things? Doesn’t simple mean that for common things, it works as expected and gives feedback that a normal human being can make sense of?

Advertisements

#uberconf groovy intro

So, groovy is basically doing ruby in java. What’s incredibly clever, aside from supporting both syntaxes and a little bit more, is translating that into something that works on the JVM. That would be kind of pointless if you were just doing groovy – why not just use ruby? – but it becomes pointful when you can integrate with whatever other Java frameworks and resources you are working with; under the covers groovy is dealing in Java objects so the translation is pretty seamless.

Or so I’m guessing, just from a quick intro. It’s pretty cool. A lifesaver if you’re stuck using the JVM!

Learning about HotSpot options; also Java = pain

While researching a customer problem yesterday I became wildly more educated about Java garbage collection than ever before. I finally know what all the talk of “generations” is about.

Also it confirms my contention that Java programmers enjoy pain. I worked with Perl for over a decade and never once had to deal with a garbage collection problem. Memory leaks, yes, but those are pretty simple in Perl – look for circular references and remove or weaken them. I’m sure things get more complicated if you’re multithreading Perl, but that’s just the thing; multithreading is still unusual in the Perl world, while it’s ubiquitous in Java. Sure, multithreading can really improve your performance, but is it really appropriate to ask every Java programmer to have to deal with the complexity it entails? I think for most projects it would be a hell of a lot cheaper to just add on a few more servers.

Anyway, to record some of the links with really interesting JVM info:

Who would believe there’d ever be such a long document about nothing but Java garbage collection? You can pick between three major collection algorithms, each with extra options of course (what goes for one generation doesn’t for another!). And as a Java programmer, you pretty much have to know this stuff, if for no other reason than because you’ll run into cryptic error messages during development. Ever run out of PermGen space while developing a webapp? What the hell does that even mean? It only makes sense once you know a fair amount about HotSpot garbage collection. Until then you just know to reload the container whenever it shows up.

I will say this for Java memory management however: it’s very cool that it handles collecting objects with circular references (which is good because they appear to be rampant). That really makes a programmer’s job easier. And it’s also cool that you have the option to collect garbage concurrently with program execution rather than having to pause everything while it’s running – although this leads to even more complexity! – and is likely the source of my customer’s problem.