svn mergeinfo probs

This helps with svn mergeinfo probs/bugs:

svn propget svn:mergeinfo --depth=infinity

To check if there is a bad mergeinfo entry in a file causing e.g . svn: Pathname not terminated by ':'

THis might also help in that regard:
http://subversion.tigris.org/issues/show_bug.cgi?id=3896

java6

With java6 many new libs were integrated directly into the jdk - without changing the classpath names. For Jaxws a custom solution(or custom cloassloader?) was integrated within a java6 update to support newer versions of jaxws so at least that worked after that. With other libraries there are still problems. For example the java activation framework. Before java6 it always had to be bundled with java mail in the war file and you had to make sure that there were no other versions in the classpath for it to work. So this worked fine with java5 - with java6 jaf was part of the system classpath but java mail wasn't. With tomcat this would result in classpath loader problems because jaf would need to use java mail classes and would throw classnotfound exceptions (if debugged) if not you would just get a classic generic no object DCH for MIME type error message.
Further information about that can be read here: http://blog.hpxn.net/2009/12/02/tomcat-java-6-and-javamail-cant-load-dch/

I really hope that in future java versions this problems can be addressed preferably by a versioned class loading mechanism. (Alternativly you could use osgi and libraries adapted for that - which would ultimately mean to avoid java system classes completely)

java the future and improvements

In the last year I often read that developers are considering to switch away from java and that java does not really evolve. For other reasons many devs also discuss if java has any future at all for them.
For many java provides a stable base for developing solid software solutions - with the backing of big companies and countless proven libraries.
Actually many of these libraries now seem dated and the language did not really change the way many devs would have expected.
For many years I thought that there are some very specific issues in java which would have to be solved for java to really evolve:

• classpath/classloader "hell" (e.g. outdated libraries shipped with the jdk, permgenspace issues)
• debugging of proxies (aspectj/spring)
• integration of osgi to allow clean lib management and better memory management

I wouldn't mind if the next java release is completely incompatible to the old java versions. In reality new java versions take years to be actually used and ready to be used.
If the next version of java has completely new basic packages (api/impl) it would break compatibility but it would allow new projects to use a cleaner and evolved environment.
Although I guess in the end devs having these requirements will switch to different languages before something like that can be achieved.

maven site:site

maven site:site used to work fine to a certain degree - but the last run was disturbed by a little exception:
java.lang.ArrayIndexOutOfBoundsException: 1         at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791)

It can be resolved by setting by setting the explicit version for the plugin:

     
        org.apache.maven.plugins
        maven-site-plugin
        2.1.1
       
       
     

although many warnings where produced like [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin.
So don't panic ;)

maven dependency conflicts

One thing about maven can be really frustrating. And it does not have anything to do with maven itself but with the repository maintaince.
Broken poms, missing jars, unmaintained 3rd party repos etc - this can result in quite a dependency hell as in the end you will need to put everything together like you did without maven. (and manual mvn install of many deps can take quite some time ..)
One thing should actually be clear - for more sophisticated projects with many dependencies - a local custom repository with which a clear dependency structure is maintained is more than necessary. This also provides a clear separation between external and internal repositories and also allows you to easily publish custom project releases and snapshots. Artifactory for example provides exactly that functionality and is easily installed and maintained.

In the end even with dependency conflicts etc - maven still provides the tools to organize your projects in a standardized way with awesome extensibility. But it should be used with care as it is not always as easy as setting the dependencies and .. go ;)

maven quirks

Things that are problematic with maven:

dependency management
correctly configured maven offers to automagically handles the dependency management of your project - after defining your projects dependencies maven will fetch them from the repository (internet) and install them in your local repository.
So far so good - the dependencies themselves usually also have dependencies and maven will fetch all of them for you.
The problems start when there dependency conflicts or references to direct implementations of e.g. loggers etc. Sometimes libraries depend on a different build of dependencies - like 1.5 builds vs 1.6 builds or a nodeps build vs a build with several smaller jar files.
To resolve that I specified exclusions and specific version imports for the dependencies in question. Netbeans offers a nice dependency viewer which even offers to view and resolve conflicts with just a mouseclick.

memory
as maven usually starts quite many task directly from the same java vm (there are exceptions which fork the java vm) you may have to be careful to offer maven enough java heap space for the build.
It is the same for ant but it should be mentioned.
(This of course depends on the size of the project)

maven

I switched from ant to maven quite a while ago and after sorting out some quirks and problems it is working nicely.
One thing that's immediately evident ist - as soon as you use maven your requirements change - as there are so many possibilities - like generating project documentation, code metrics and so on.
There are also so many interesting plugins/mojos available that soon you will like and use.
The maven integration in netbeans(6.8) is also great and even superior to the ant project system in my opinion because of the higher feature set which is provided by maven out of the box.
There are definitly things to sort out when using maven - and it is far from perfect but i think it offers a nice standardized way to organize and build projects with the possibilty to add plugins easily.