• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Creating manifest.mf file with class-path entry without version info. (am using mvn jar:jar)

 
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am using maven 2.0.9 as a build tool. To build a jar from my code, I use the maven command

c:\>mvn jar:jar



This creates a jar file with a manifest.mf within.
But, the class-path entry that I get in the manifest.mf is in maven style,

In manifest.mf getting:
Class-Path: xstream-1.2.2.jar annogen-0.1.0.jar mina-core-1.1.5.jar jdom-1.0.jar backport-util-concurrent-1.4.jar


Is there any setting for the maven plugin, which can strip out the version info, and build the jar with manifest.mf with version info stripped out

In manifest.mf the Class-Path is desired as

Class-Path: xstream.jar annogen.jar mina-core.jar jdom.jar backport-util-concurrent.jar



~g1
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What's complaining about this?

In manifest.mf expected:
Class-Path: xstream.jar annogen.jar mina-core.jar jdom.jar backport-util-concurrent.jar

The versioning info should be OK.
 
Jeevan Sunkersett
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes Martijn,

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.

~g1

 
Martijn Verburg
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think your cron job should execute the properly versioned Jar , I'm not sure how you can strip out the version info.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic