You are right, even with versioning it should be okay.
However in my scenario, the jar is part of a EAR.
Used and executed, as j2EE dependeny, by the web application; deployed in side of gerinomo. (all business logic exists in the .jar)
But a requirement exists, to execute business logic via a cron scheduler; using java -jar ApplicationBizLogic.jar
When the maven build prepares the EAR and deploys it on gernimo, all shared libraries/ jars in <APP-SERVER>\shared\lib are without the version info;
while the manifest.mf in the ApplicationBizLogic.jar has version info in the Class-Path
and so cannot be executed using java -jar ApplicationBizLogic.jar.
So my query, on how to strip out version-info, in the maven jar plugin.
I'm unclear on what you're actually doing, but here's what you need to be doing, anyway:
1. Make a Maven project for the executable JAR with the backend business logic in it.
2. Make a Maven project for the EAR. The executable JAR should be a dependency.
Also note that a stock executable JAR isn't like a WAR or EAR where you can throw dependent JARs into the primary JAR file and have them found by the classloader. So you either have to explode all the library JARS then add them to the primary structure of the executable JAR or you have to explicitly add a classpath to the execution command line and forgo the "java -jar" mode of execution.
There is a Maven plugin that gets around that - I think it adds a custom classloader to the executable JAR. It also produces a stock JAR without the embedded dependent jars and classloader, which is probably going to be what the EAR dependency pulls.
Another approach, which I've done is to make the business logic be an RMI server and have the webserver invoke it. You could turn that inside out and make the business logic be EJBs, but I'm considering that the reason you have a cron invocation is that there's probably some heavy-duty processing going on that you don't want to inflict on the appserver. In my case, about 4 million transactions had to be run and each transaction was fairly hungry.
Depending on the coupling, an ESB-style approach might be worth considering, too.
An IDE is no substitute for an Intelligent Developer.