In the Java world, we're used to having a (sometimes long) list of exceptions specified, indicating which kinds of errors a method may report. I have some issues with the implementation of this in Java (more on this when I can be bothered to write a few pages), but at least the errors are part of the interface. This makes it possible to write correct code. Not so in Windows:
"The error codes returned by a function are not part of the Windows API specification and can vary by operating system or device driver. For this reason, we cannot provide the complete list of error codes that can be returned by each function. There are also many functions whose documentation does not include even a partial list of error codes that can be returned."
http://msdn.microsoft.com/en-us/library/ms679360(VS.85).aspx
Avoid. Trust me.
2009-03-10
jar indexing and hivemind
I have only read about jar-indexing but never used it. It is supposed to speed up classloading when using several JARs. I can certainly tell you it speeded up my program since it went from working to failing very fast.
Let me explain. I have a Swing-application that uses hivemind as IoC-container. Hivemind is sweet, it discovers injection information automatically from all jar-files on the classpath. It uses a pretty simple getResource to get all files called META-INF/hivemodule.xml regardless of hte JAR-file they live in.
So I have an executable jar-file (you know, with the main-class attribute in the manifest file). It has a Class-Path attribute that points to some other JAR-files. This has always worked before I started converting my build scripts to maven.
Since I mindlessly copied the example from the jar-plugin page (http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html) the maven JAR-plugin created the jar-index file INDEX.LST.
With this index file in the jar hivemind failes almost directly.
I guess it is because the index file did not contain the dynamically loaded resources, at least that is the spec for INDEX.LST. If it exists it is trusted to contain everything needed. Since the jar-plugin did not index my dynamically loaded resources they simply do not exist as far as the classloader goes.
You learn something new every day.
Let me explain. I have a Swing-application that uses hivemind as IoC-container. Hivemind is sweet, it discovers injection information automatically from all jar-files on the classpath. It uses a pretty simple getResource to get all files called META-INF/hivemodule.xml regardless of hte JAR-file they live in.
So I have an executable jar-file (you know, with the main-class attribute in the manifest file). It has a Class-Path attribute that points to some other JAR-files. This has always worked before I started converting my build scripts to maven.
Since I mindlessly copied the example from the jar-plugin page (http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html) the maven JAR-plugin created the jar-index file INDEX.LST.
With this index file in the jar hivemind failes almost directly.
I guess it is because the index file did not contain the dynamically loaded resources, at least that is the spec for INDEX.LST. If it exists it is trusted to contain everything needed. Since the jar-plugin did not index my dynamically loaded resources they simply do not exist as far as the classloader goes.
You learn something new every day.
2009-03-04
maven sites
So I decided to give maven another go for my small home projects. Last time I tried it was Maven 1 and I ran crying back to Ant+Ivy.
I wanted all those cool maven sites for my projects since the reporting stuff is really nice. Now, I have a multi-module build system. In my old Ant builds that was convinient for producing the web site and get the navigation linked between parent and child projects. So I used the same directory layout and that's when the strange stuff started. As is usual with maven the documentation is lacking here and there although it is much better now than in the Maven 1 days. But I understood from the documentation that maven would produce module links for the reactor build.
Having come to grips with the site:staging-funny stuff I noticed that it did generate a module menu. However it was empty. Try as I might I just could not get it to generate a link to the module project.
I "solved" it by letting the child project have the parent project as parent in the pom.
Now, this is mighty strange to me. I actually do not want the project in the higher directories to be parent pom:s. I do not want to inherit settings that way. Actually I do not want to inherit anything. I want the projects to be self contained apart from the tags.
I guess what I really want is for the site mojo to find the tag. Understand that it should generate a module link. Then go to the module itself and look at the URL for that project and use that for a link target. It might even go as far as looking at the URL and find out if it is a relative link. If not it can try to make it relative. But I do not understand why the child must point to the parent to generate the module links.
When I ran into problems with maven:stage when one if the modules was in itself a pom-pom with modules itself I gave up and made a flat directory structure. Maven site is cool, or rather, the reporting is cool and links to that is nice. Maven site in itself does not zoom.
Funny that my Ant-version of the site mojo is actually two pretty simple XSLT-files :-) I know that isn't a fair comparison but still.
So since I grew tired of subversion I tried bazaar. The IDE integration is lacking and the trac-plugin sort of works halfway I decided to try Mercurial. So far I've noticed that it works for simple use cases and that Ubuntu Intrepid packs version 1.0.1 and not the 1.1.2 release of mercurial. Hope they start using the newer stuff but I guess Canonical is more interested in pushing bazaar. Can't blame them since bazaar is sweet.
I wanted all those cool maven sites for my projects since the reporting stuff is really nice. Now, I have a multi-module build system. In my old Ant builds that was convinient for producing the web site and get the navigation linked between parent and child projects. So I used the same directory layout and that's when the strange stuff started. As is usual with maven the documentation is lacking here and there although it is much better now than in the Maven 1 days. But I understood from the documentation that maven would produce module links for the reactor build.
Having come to grips with the site:staging-funny stuff I noticed that it did generate a module menu. However it was empty. Try as I might I just could not get it to generate a link to the module project.
I "solved" it by letting the child project have the parent project as parent in the pom.
Now, this is mighty strange to me. I actually do not want the project in the higher directories to be parent pom:s. I do not want to inherit settings that way. Actually I do not want to inherit anything. I want the projects to be self contained apart from the
I guess what I really want is for the site mojo to find the
When I ran into problems with maven:stage when one if the modules was in itself a pom-pom with modules itself I gave up and made a flat directory structure. Maven site is cool, or rather, the reporting is cool and links to that is nice. Maven site in itself does not zoom.
Funny that my Ant-version of the site mojo is actually two pretty simple XSLT-files :-) I know that isn't a fair comparison but still.
So since I grew tired of subversion I tried bazaar. The IDE integration is lacking and the trac-plugin sort of works halfway I decided to try Mercurial. So far I've noticed that it works for simple use cases and that Ubuntu Intrepid packs version 1.0.1 and not the 1.1.2 release of mercurial. Hope they start using the newer stuff but I guess Canonical is more interested in pushing bazaar. Can't blame them since bazaar is sweet.
Subscribe to:
Posts (Atom)