Keep The Environment Clean!

zelmak

So, we have a small plug-in infrastructure in our Java code base.

In order to work, your plug-in has to

Match the signature of the plug-in interface class. Makes perfect sense.
Be added to the configuration file in the appropriate places. Okay, no biggie there.
Your plug-in may be several Java classes in separate class files. Fine, fine.
However, your plug-in needs to be built and reside in the package/namespace "plugin." Um, what?
Also, you can't simply add your plug-in class files or JAR-based library to the classpath. No. It has to be incorporated into the system's plugin.jar file. Waitaminute, what?

In order to do this incorporation, our predecessors invented this hob-goblin of a mess in the ant build script:

<!-- deploy plugin support to target deployment area -->
<TARGET if="argument" name="deploy-plugins">
<MKDIR dir="${argument}/java/lib/tmp">
<UNJAR dest="${argument}/java/lib/tmp">

<FILESET dir="${argument}">

<INCLUDE name="/*.jar" />

<EXCLUDE name="/plugins.jar" />

</FILESET>

</UNJAR>
<DELETE file="${argument}/java/lib/plugins.jar">
<JAR basedir="${argument}/java/lib/tmp" destfile="${argument}/java/lib/plugins.jar">

<PATTERNSET>

<INCLUDE name="**/*.class"></INCLUDE>

</PATTERNSET>

</JAR>
<DELETE file="${argument}/java/lib/tmp">
</TARGET>

Apparently, there was a great debate at the time: do these plug-ins belong with the baseline source and compiled with it or can they be separately compiled against the mainline source and included later. This was apparently the compromise between the two warring factions.

Essentially:

Go to the deployment directory and unzip all the files in the current plug-in JAR-based library to a temporary location as well as any JAR file in any subdirectory of the deployment directory.
DELETE (without backup) the original deployment JAR-based library.
OVERWRITE (without backup) the original deployment Java class files in the temporary directory with any updates from the deployed JARs.
Rebuild the original JAR-based library with the contents of the temporary directory.
DELETE (without backup) the Java class files in the temporary directory.

All these race-conditions, possible filename collisions and other WTFs ultimately do is keep the CLASSPATH environment variable 'clean' (instead of simply adding each plug-in JAR file to the classpath.)

Xyro

Whoa, no way, I could have sworn I read this one before... Could it be that you're working for the same company for which another TDWTFer worked or works??? :O

...lemme google this...

Oh wait. [url=http://forums.thedailywtf.com/forums/p/25382/273802.aspx]It was you.[/url]

zelmak

@Xyro said:

Whoa, no way, I could have sworn I read this one before... Could it be that you're working for the same company for which another TDWTFer worked or works??? :O
...lemme google this...

Oh wait. It was you.

Oops ... I THOUGHT I'd posted this before, but I couldn't find it with search. Consider this a Classic Side-Bar WTF ... :)

Xyro

@zelmak said:

but I couldn't find it with search

Never use the CS search feature! It's useless!

For that matter, never use any CS feature! They're all useless!

For that matter, never use CS! It's useless!

ubersoldat

If it makes you feel any better, I believe this post is better than the previous one because you provide more XML! We love XML around here.

Anyway you put it, it's still stupid though.

Severity_One

They've had the ServiceLoader interface since Java 6, so at least three years before your original post. This can be done completely transparently and elegantly.

But then, what would there be to discuss at TheDailyWTF?

pjt33

@Severity One said:

They've had the ServiceLoader interface since Java 6, so at least three years before your original post. This can be done completely transparently and elegantly.

And they've had the ability to add a class loader since what, 1.0? It just takes a few lines to register all the jars in a directory without having to clutter up the CLASSPATH.

zelmak

@pjt33 said:

@Severity One said:
They've had the ServiceLoader interface since Java 6, so at least three years before your original post. This can be done completely transparently and elegantly.

And they've had the ability to add a class loader since what, 1.0? It just takes a few lines to register all the jars in a directory without having to clutter up the CLASSPATH.

Actually, I often think our predecessors built this codebase on some pre-release beta (gamma?) version of Java which predates 1.0.