I discovered this when I changed my build script to only resolve ‘master’ before publishing a snapshot to a local repo, because I wanted local publishes to be extremely fast. I guess it’s ok for local snapshots to carry dynamic revisions, but it’s probably a good idea to always do a full resolve before publishing a release.

To use the class, drop the class on you Ant classpath, then declare the task like so:

It's a standard Ivy post-resolve task. What that means is a) it takes the same common attribute set as any other post-resolve tasks would, and b) it must be run after an ivy:resolve call. For example, every time the following line

executes, the entries in .classpath that were generated from the previous run are removed, and new entries added according to the latest ivy:resolve result on ivy conf "provided" and "testtime". The entries generated by this task are marked with an attribute, ivygen="true", so any entries you manually added are not impacted. Note: if you have added classpath entries manually for the dependencies in ivy.xml, before running this task for the first time ever, it's a good idea to remove all of them, otherwise you'll end up with duplicated entries.

To invoke the source jar attachment support, just add to the ivy.xml references to the source jars. For example:

would add hibernate-core's source jar to ivy conf named "references". Then make sure to include conf "references" in the ivy:resolve call, such as:

The classpath entries updated will then also have the corresponding source jars (if available) attached.

Here's the source code for the task.

Fortunately I have a Nexus repository as the aggregator/proxy to all the external repositories. Brian from the Nexus IRC room pointed me to this solution/workaround: add the fixed maven-metadata.xml to a repo hosted by Nexus - e.g., the "3rd Party" repo coming out of box in Nexus. Then create a group to aggregate the 3rd Party and the public Ibiblio repos. The "virtual" group repo will automatically create a merged maven-metadata.xml on the fly whenever it is requested.

And it works like a charm. Thanks, Brian!

org.hibernate.MappingException: multiple or zero characters found parsing string

Turns out if the discriminator type is "character", the base class must have a discriminator-value attribute declared, even though obviously due to the abstractness there will never be any row carrying that discriminator value. And apparently for "string" type discriminators, there isn't such a limitation.

1. Copy freemarker-2.3.13.jar into $ECLIPSE_INSTALLATION/plugins/org.jboss.ide.eclipse.freemarker_1.0.0.GA, and remove the freemarker-2.3.8.jar in there.
2. Edit META-INF/MANIFEST.MF to replace the reference to "freemarker-2.3.8.jar" with "freemarker-2.3.13.jar".
3. Restart Eclipse with the "-clean" command line option. This is important because otherwise the Eclipse OSGI engine will keep using cached bundle data which is stale now.

And here comes the second layer of strangeness - I also have an ubuntu virtualbox machine running in the same box, with the same JDK version, same setup, and the same source tree. And it works just fine in there.

So fast-forward through a few hours of hair pulling, the two workarounds I eventually figured out are:

• The /etc/nsswitch.conf file out-of-box has a line looking like this:
  hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
  Apparently the name resolution code in JVM (e.g. InetAddress.getByName() and friends) doesn't like the multicasting DNS (represented by 'mdns4_minimal').
  Move 'dns' up so it looks like:
  hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
  solves the problem. On the other hand, I haven't observed any negative effect of this change on any of the non-Java applications.
• If you are not comfortable with or don't have control over changing a box-wide config file, another workaround is to set the system property java.net.preferIPv4Stack to true when starting a Java application (maven in my case) which needs to do name resolution.

So how come the default works fine in the virtual machine? My theory is that when running in there, the virtualbox NAT code running in the guest OS is called for name resolution during 'files'-based resolution, and is able to handle it by delegating to the host OS.

Until beta 2, Ivy finds out about the available versions of a module by parsing the directory listing HTML from Ibiblio's Apache server. That doesn't work when there is a proxy server sitting in between, because a) the proxy server doesn't usually proxy directory listing requests, and/or b) the proxy server renders the directory listing in different HTML. Switching to using the structured maven meta data completely eliminated this mess.

Of course, using the maven-metadata.xml files from the official ibiblio repository will subject us to some new hazard - some modules have out-of-date maven-metadata.xml. For instance, by its maven-metadata.xml, the latest version of Hibernate would still be 3.2.0.cr1.

One of those maven proxy servers turns out to be a perfect solution to this problem - we can use them now, remember? In my case, I run an Archiva server proxying the official maven 2 repository. Whenever I run into a bad metadata file, I simply request the missing version through Archiva, and it will fetch it and update the metadata file. For example, in the hibernate case, I would just open up Firefox and try to download http://archiva-server/repository/internal/org/hibernate/hibernate/3.2.6.ga/hibernate-3.2.6.ga.jar. That only needs to be done once, and afterwards Archiva would have updated its local version of the maven-metadata.xml properly.

As an example, say I would like to organize the interfaces/classes that constitute an order handling API into a com.foo.order package, such as:

• Order - the aggregation root of the domain.
• LineItem - the entity class that represents each line item on an order. Each order has a list of line items.
• OrderService - an interface for an order handling service.
• OrderRepostiory - a repository interface for access the order objects.

And I'd like the implementation classes kept in a com.foo.order.impl sub-package, which would have, of course, OrderServiceImpl and OrderRepositoryImpl.

Now the problem comes. On the Order class, as part of the domain API, I have public methods controlling access to the line items by index, e.g., getLineItem(int i). In the meantime, I would like to provide a method setLineItems(List items) so that the repository implementation can efficiently set the list of line items read from the database. Obviously that method should not be public, as it defeats the purpose of any other controlled accessors. On the other hand, there is no way other than making the method public for it to be accessible to the repository implementation, due to it being in a different package.

It seems to be quite a natural thing to me for Java to support an extra level of access - the sub-package level. It would be between public and the default access - only classes in the same package or the sub-packages can access members declared at this level.

Say we have two classes:

In the context file, a simpe one-liner

gets the above two beans wired together (or any number of other beans as long as they are properly annotated with the two markers).

Easy, right? Well, the only problem is that those two imports make our otherwise nice domain class depending on some Spring infrastructure. Fortunately, with a little extra config, we can remove this dependency.

First we create our own annotation classes. In this case I simply copied the two Spring ones into my package structure, with the code itself remaining the same. So I won't bother to post it here. Bottom line is now we have our own sandbox.spring.annotation.Component and sandbox.spring.annotation.Autowired.

So now we replace the Spring annotation classes in those imports with our own versions, and change that one-liner above to:

Basically the autowiredAnnotationBeanPostProcessor bean definition defines a customized BeanPostProcessor that looks for our own Autowired annotation instead of the default one. And then the <context:component-scan> element overrides the default Component annotation with our version.

Note that it's important to have the annotation-config="false" above, for it turns off the default BeanPostProcessors.

Also worth noting is that the extra config is applied to all other annotated beans, so despite it might look overly complicated in this case, it's really trivial in any serious context where hundreds of beans could benefit from this same piece of config.

Similar to the two annotations discussed above, pretty much all others (such as @Required) can be substituted with customized versions via similar configuration.

I have never been a big fan of annotation-based configuration. One of my biggest concerns - and perhaps the only practical one - is the compile-time coupling it introduces. With this unintrusive way being introduced in Spring 2.5, I find annotation-based configuration a strategy more valid than ever.

I also realize that you feel stronger urge to enforce exception handling in contracts than I do, because of another philosophical difference - I think things like "insufficient balance" aren't really exceptions, and should be expressed as the status of an account or a transaction in a first-class domain object.

But I guess that's an even finer line to draw, so, another debate for another day...

Well, I guess that "other day" has come.:-)

Basically Debasish is promoting the approach to handle alternate business flows with checked exceptions, like so (sample code quoted from his post):

Now, to me, that begs for the question: how is that, in essence, different from doing:

I believe doing unnecessary type-based branching like that is generally considered very un-OO. I probably wouldn't hire myself if I wrote code like that in an interview. Why, then, should it be considered a legitimate pattern simply after being dressed up in a try-catch block?

Of course, I hear the argument that "the compiler then enforces the handling for you". And that would bring it back to my original debate with Debash, in which my main point was that the way checked exceptions are designed in Java to "help" enforcing contracts is highly intrusive - quoting my own comments from Debasish's blog:

"I would like to force the caller of my api..." that's the philosophy I'm against really - checked exception is just the expression of that philosophy on the surface.

And the reason is very simple - I can't find any software engineering doctrine that says the callee mandating the caller's logical flow is a good thing. Imagine a language where an API can explicitly define rules for its callers like "you must have an alternate flow to deal with my return value if it's 0,1,or 2." That would sound crazy, but it's essentially the same as checked exceptions in Java.

Other languages learned from Java's mistake - C# exceptions are all unchecked, for instance.
...
I absolutely agree with you that exceptions are part of the contract. However, IMHO, an API contract should _not_ dictate implementation - either way for that matter. That an exception is part of the contract only goes as far as saying "be _prepared_ to handle this exception," but not "you _must_ handle this exception right here right now."

Again let's use the return value analogy - it's perfectly fine for a contract to say "I might return null so don't be surprised when you see one," but it's rather excessive to say "you must have an if testing my return value and do something differently if it's null."

One obvious solution to the problem is to always explicitly get the bean reference from the Spring context and then call the method on it, instead of calling the method on 'this'. For example, instead of this.anotherServiceMethod(), do:

It's an easy solution, but one that doesn't come without a few nuisances. For instance, it adds to your service bean some compile-time dependencies on Spring classes that wouldn't have been necessary otherwise.

One less intrusive solution I've come up with is a AdviceSkippingInjector.java that injects the reference to any proxied Spring bean into a property on the "raw" bean, i.e., the object prior to being wrapped in the proxy.

To use it, add a proxiedSelf property to the service bean (it doesn't have to be on any public interface), add this to your context file:

In the map beanProperties, each key is a bean name defined in the context, and the corresponding value a property name on the bean. At run-time, if the AdviceSkippingInjector sees a bean name in its map, it will drill into the proxies, find the reference to the original bean, and inject the reference to the proxy into the original bean's proxiedSelf property.

This solution is unintrusive because the service bean remains unaware of any of the plumbing work. All the wiring is done in the application context. In fact, the service bean isn't even necessarily aware that proxiedSelf, despite the name, points to its "proxied self".

What do I like about Ivy? Well, let me start with the fact that it doesn't try to reinvent Ant, but rather serves as an extension to Ant (and can also run stand-alone outside any Ant context). It is essentially a dependency management engine - it focuses on being a good one at that, and once dependencies are resolved and retrieved, it stays out of the way for the rest of the build process.

Ivy offers a powerful expression language for specifying a variety of version patterns. There can be patterns like "1.4.+", which can be satisfied by any version later than 1.4, "[1.4,)", which means any version of 1.4 or after, or "[1.4,1.9], which selects any version between 1.4 and 1.9, including both.

The concept of "configuration" in Ivy also comes in very handy when you need to categorize the dependencies, and influence how classpaths ought to be assembled according to the different contexts they'll be used in - e.g., I was able to define configurations called "build", "test", "coverage" to deal with dependencies required at build-time, test-time, and test-with-emma-the-coverage-tool-time.

Another strong selling point of Ivy is that it has built-in support to leverage the existing ibiblio maven repositories. Ivy's ibiblio resolver works with maven 1 repository by default, but can be set in "m2compatible" mode with one attribute flip. The more universal URL resolver in Ivy can work with pretty much any repository structure whose paths are defined in patterns. Although for most practical projects, the out-of-box ibiblio support, combined with the cache resolver that tries to resolve artifacts in the local cache first, would suffice very well.

The one caveat I found out, though, is that at the moment the ibilbio resolver doesn't handle the directory listing of some existing maven repository proxy tools, such as maven-proxy and proximity. So the dynamic version resolving (such as range or wildcarded version numbers) feature, relying on the resolver parsing directory listing to discover available versions, won't work when there is a ibiblio resolver points to a proxy server. According to the developers, this issue is definitely on the radar and hopefully will be addressed by the time the next major version (2.0) comes out. Possible workarounds I'm contemplating on include setting up a reverse proxy with an internal apache server, or adding an extra Ivy resolver pointing to the internal repository. I'll try those and report back.

As Ivy has recently been taken under the Apache wings, and become an Apache Incubator project, I hold high hope on its codebase maturing rapidly and eventually graduates to be yet another great Apache tool. I believe as far as build management is concerned, Ivy offers a great opportunity to leverage and combine the two valuable assets the Java community has built over the years - the mature Ant toolset and the sophisticated ibiblio maven repositories. As Colin Sampaleanu pointed out, the decision to use Ivy is a no-brainer.

This did get me thinking, though - and let me preemptively clarify that "Yahoo is evil" is definitely not what I'm about to get at. And I truly appreciate this offering as a noble intention and a community-friendly move, rather than any sleek public image stunt. Nevertheless, if we look at it in the whole bigger picture of "where F/OSS is going today", this is yet another instance of a big corporation leveraging its muscle to support an F/OSS project. Regardless of Yahoo's intention, in reality, there is still the feeling of a lesser leveling playground for those other projects without any backing.

The beauty of Java the Language, IMHO, is its simplicity. Many people, including myself, coming from a C/C++ background immediately appreciate the fact that there is much, much less surprise in code written in Java. Every spoonful of syntax sugar added to the language adds to the conceptual complexity of the language, not linearly, but exponentially, as every new construct has to work well with everyone that's already in there. On the other hand, it only makes things easier superficially. What does a closure gain us? A few lines of less typing? Or maybe just a few key strokes in any of the modern IDE's these days?

Many people say that closures are easier to learn for beginners than anonymous classes. I wouldn't be so sure. For instance, which one is easier: to explain to a student that that mysterious Foo$1.class is actually generated from a closure which, whilst not being a class conceptually, actually is handled as an anonymous class? or to explain to him that an anonymous class gets compiled into, well, a class?

Furthermore, should everything that makes Java easier to use make into the language? Dependency Injection/IoC Containers have become more and more widely adopted, but that doesn't mean Java should necessarily incorporate Spring or Hivemind's definition syntax, does it?

Some people say syntax sugar is supposed to make Java easier to use, so it can compete with RoR, .Net, etc. I agree to the goal, but not the means. IMHO, the changes that Java, especially enterprise Java, needs in order to go up against Microsoft and RoR/the whole LAMP camp have to be much, much more fundamental than throwing in several sugar cubes. EJB 3 is a good move in that direction, as Java admits that miserable mess happens when the principle of simplicity is forgotten. But there is yet a lot left to be desired, for example, until JVM starts supporting compartmental deployment, i.e., multiple applications running and managed in isolation, there is no hope for Java to become a strong offering in the Web hosting market. Unfortunately, AFAIK, JDK 7 has yet no plans of supporting that.

I did some googling and actually found a couple of "Java tutorial" sites that tell people to override clone() as part of a "standard" singleton implementation. I won't be linking to any of those sites for the obvious reason of not wanting to bump up their google rankings. And I'm just gonna post some kind of "counter-jinx" here:

If you are preparing for an interview, and happen to stumble upon this blog, please, please remember that Object.clone() by default throws CloneNotSupportException if the class does not implement Cloneable, and I don't really think you would want to tell your interviewer that you wish to have your singleton class implementing Cloneable. So, no, it's completely unnecessary to override the clone() method in a singleton implementation.

The sample code above creates two bean definitions, the second one referencing the first.

Another thing that had some coffee-spilling effect on me was the "Closures, Lambdas and friends" part. On the first look, I thought they were adding "friend" support in Java 7 (as in C++), which would have been a good thing.