Announcement: Version 99 Does Not Exist
In a previous post I announced no-commons-logging (a.k.a. commons-logging version 99.0-does-not-exist). After a request to add no-commons-logging-api I immediately realized that this can be generalized. So here it is: Version 99 Does Not Exist.
Features
Version 99 Does Not Exist emulates a Maven 2 repository and serves empty jars for any valid package that has version number 99.0-does-not-exist. It also generates poms, metadata files and of course the appropriate hashes.
For example the following links will give an empty jar, its pom and the maven metadata for commons-logging.
Why?
To get rid of dependencies that maven 2 insists on including on your classpath (like commons-logging while you want to use jcl-over-slf4j).
How do you use it?
First of all: if you were using no-commons-logging before, you do not need to change anything! Version 99 Does Not Exist is fully backward compatible with no-commons-logging. Otherwise, read on.
In your pom.xml declare the following 2 things: 1) the Version 99 Does Not Exist repository, and 2) for each jar that you get but do not want, declare a dependency with version 99.0-does-not-exist.
So, for example, if you do not want to be bothered with commons-logging, include the following in your pom.xml:
<repositories>
<repository>
<id>Version99</id>
<name>Version 99 Does Not Exist Maven repository</name>
<layout>default</layout>
<url>http://no-commons-logging.zapto.org/mvn2</url>
</repository>
</repositories>
<dependencies>
<!-- get empty jar instead of commons-logging -->
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>99.0-does-not-exist</version>
</dependency>
</dependencies>
When?
Right now. As I received questions on how stable this service will be, I hereby promise to keep this maven repository on-line for at least 5 years (or until no-ip stops offering their free dns service). Read further if you want to run Version 99 Does Not Exist yourself.
How?
Version 99 Does Not Exist is implemented in a single file as a Camping application.
Where is the code?
If you want to run it yourself you'll need the following: Version 99 Does Not Exist download (rb file, 4Kb, MIT license), Ruby, Ruby Gems and Camping. Version 99 Does Not Exist is started with a simple camping version99.rb. Good camping!
Update 2007-11-06: The empty jar is no longer completely empty as 'mvn site' fails on it. Thanks to Stefan Fußenegger for the report.
Update 2007-12-14: The repository was off line for a day or so because I goofed while switching internet provider. Now, it is not only working again, but reachability is better then ever: 10 Mbit/s up and down!
Update 2008-02-09: Version 1.2: another update to the empty jar. Sasha Ovsankin reported that the compiler could not open it. The jar now contains a valid manifest. Thanks Sacha!

14 comments:
Wow, cool! For something like this camping seems to be really useful. Seems like te right tool for the right job!
I probably miss something but isn't
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl104-over-slf4j</artifactId>
<scope>runtime</scope>
</dependency>
exactly what you want?
@joern: Thanks Joern. After many days of plain misunderstanding and struggling with maven bugs(?) I gave up and wrote this workaround.
But I'll try your suggestion next week.
@joern: Actually your solution is different!
The "provided" scope makes sure commons-logging is not put in the distribution; but commons-logging classes will still be on the classpath at compiletime or when running tests which might not be what you want!
Ah! Thanks Peter. Indeed you are right. I had forgotten already. That probably illustrates that Maven is a tad too difficult, or put otherwise: Maven is only suitable for people with very large brains, or yet another way: its for people that do not have much else to do :)
Hey thanks for your effort here! I just your little repository and figured one thing out: if you are working with ranges like
<dependency>
<groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId>
<version>[5.0,)</version>
</dependency>
you are screwed, as maven will add mysql-connector-java-99.0-does-not-exist to the classpath. everybody using your hack should consider this!
Another thing: I also get this when running `mvn site`:
error: error reading repo\commons-logging\commons-logging\99.0-does-not-exis
t\commons-logging-99.0-does-not-exist.jar; error in opening zip file
I don't know which task fails and I don't have to much time for fiddling around with maven right now, but I guess it is expecting some files in the jar files and throws an exception as the jar/zip is empty. Probably adding a simple README to the file would make this plugin (and maybe others) happy.
Regards, Stefan
the task that fails with commons-logging-99.0-does-not-exist is compiler:testCompile. I added a README to the jar file and everything works fine again ... so I guess I have too much time ;)
Thanks Stefan! I'll add a readme to the jar as soon as possible.
About the open ended versions: I would never like to work that way, far to risky! But in a way, all software will eventually be obsolete, so it makes sense ;)
hi erik,
isn't it kind of frustrating to think that all software that you write will be obsolete in the end ;)
I like working with open ranges in a very early development/prototype stage ... and I just like to live on the edge ;)
In deed, I agree that using open ranges is too dangerous. Tough I'd use versions like [1.2.3,1.3) or [1.2.3,2.0) in order to get the latest bugfixes etc.
I just forgot to close one of those ranges and ended up with a useless mysql connector. Therefore I wanted to drop a (short?) note for everybody.
Ha! It is no less frustrating then the end of life itself! ;)
Thanks for the note though.
hi erik,
i just came back to see if you patched the file and i've seen that you did today ... thanks a lot!
regards, stefan
Hi Erik,
Thanks for the great hack. For some reason, it didn't work in my build because the compiler would reject the JAR file. Here is the link to a file that works for me:
http://www.codebistro.com/commons-logging-99.0-does-not-exist.jar
Thanks,
-- Sasha
Hi, could you please do the same for commons-logging-api module? Thanks.
Bigs ups man. You a medal.
Post a Comment